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Title; SYSTEM TO FACILITATE ANALYSIS AND/OR PLANNING OF 
BUSINESS OPERATIONS 

Technical Field 

5 The present invention generally relates to computer programming and, more 

particularly, to a system and method to fecilitate evaluation and/or analysis of business 
operations, which may include budgeting, forecasting, tend analysis, and/or planning. 

iQ In order to remain competitive in any business, the business and each of its 

individual parts or business units must run efficiently to meet or exceed the demands of 
its customers. For example, in the hospitality industry, a typical facility, such as a hotel, 
spa, or other hospitality facility, includes several areas of operation. Each area of 
operation requires a certain .level of personnel, maintenance, supplies, and management 

$ S daring each year. In the hospitali ty industry the day-to-day needs of each area operation 
are subject to significant change, which the management responsible for each area of the 
facility must accommodate. Accordingly, an important aspect of operation is budgeting 
and forecasting to properly adapt to the changing circumstances so as to maximize 
profits. 

20 A facility, such as a hotel, may include several business units, each of which may 

have an impact on hotel operation. The hotel may have several points of sale (PCS), such 
as restaurants, bars, etc, where customers perform commercial transactions. Also within 
a hotel are other business units that provide other hotel sendees to customers. Each 
business unit may maintain a record of its associated activities, winch may he stored in an 

25 associated computer database. Other aspects of hotel operation, such as payroll and 
accounts payable, sales and catering, etc., also employ a system for accumulating 
information on each respective aspect of its operation. Each system usually operates 

each mai nuiinmg its own records, which may be kept on paper or stored in 

computer files, 

30 Historically, there has been little centralized budget planning in* 1 i 

industry. For exampte, each business unit within a hotel may have its own budget. 
Moreover, each budget may be produced with a different tool That is, one business unit 

I 
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may keep its books using pen and paper, another business unit may employ a 
cons nerd v V. and yet another may utilize a commercial software 

business package to keep its books. Even when business units may keep their books 
ekctroakaSy and employ the same software (e.g., a spread sheet), a department head or 
other individual responsible for the performing a budget analysis and/or forecasting may 
require different data fields pertinent to that unit's budgeting and/or forecasting. 
Additionally, each data set may be stored in. a unique record format selected by that 
individual 

As a result, diverse databases, file systems, and data sources, often employing 
l o several unique record formate, may have evolved for numerous business units within a 
single company or other type of business organization. Consequently, within a 
management organization responsible tor several business units, the diversity of 
databases and record formats is compounded as various databases, computer file systems 
and data sources may have evolved, thus resulting in numerous unique and inconsistent 
1.5 record formats. As a result, it may take several individuals weeks or even months to enter 
appropriate data and prepare an annual budget for a given facility. Moreover, accurate 
forecasting may further be hindered, as it. tends to be complicated to correlate historical 
data among such diverse types of data. 

The present invention relates to a system to facilitate budgeting and/or forecasting 
for a business organization. 

One aspect of the present, invention provides a system to facilitate, budgeting 
and/or forecasting. The system includes a database which stores account data for a 
25 plurality of accounts of a chart of accounts, the account data being indicative of operating 
characteristics for the plurality of accounts for a plurality of days over a time period, A 
method is associated with each account of the plurality of accounts for correlating 
selected account data and calculating an expected account value for each respective 
account of the pi anility of accounts as a function of the correlated account data. 
30 Another aspect of the present invention provides a system to facilitate budgeting, 

planning, and/or forecasting. The system includes a database which stores account data 
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for a plurality of accounts of a chart of accounts, the account data being indicative of 
< ' - > v ity of accounts o er a time period. A budget 

aior component is piogrammed to selectively generate budget data for at least some 
accounts of the plurality of accounts based on the stored account data. An impact 
5 component is programmed to apply an impact value to the budget data to adjust the 
budget data for at least one account of the at least some accounts as a function of the 
impact value. 

To the accomplishment of the foregoing and related ends, certain illustrative 
aspects of the invention are described herein in connection with the. following description 
AO and the annexed drawings. These aspects are indicative, however, of but a few of the 
various ways in which the principles of the invention may be employed and the present 
invention is intended to include all such aspects and their equivalents. Other advantagi 
and novel features of the invention will become apparent from the following detailed 
description of the invention when considered in conjunction with the drawings. 

15 

Fig, 1 Is block diagram of a system for facilitating budgeting and/or forecasting in 
accordance with the present invention; 

Fig 2 Is Sf hematu i ii ustrating a system for collecting data from a 

20 plurality of data sources to facilitate budgeting and/or forecasting in accordance with the 
present invention; 

Fig. 3 is a functional block diagram illustrating a system for converting data to 
desired record formats in accordance with the present invention; 

Fig. 4 is a functional block representation of a system for facilitating budgeting 
25 and/or forecasting in accordance with the present invention; 

Fig. S is a table illustrating an example of an account data structure that may be 
utilized in a system in accordance with die present invention; 

Fig. 6 is a block representation of an exemplary hierarchy of accounts that may be 
.. $ . in a system in accordance with the present invention; 
30 Fig. 7 is an example of a graphical user interface that may be employed to manage 

a chart of accoun ts in accordance with the present invention; 
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Pig. 8 illustrates & functional block representation of an aecimmlator far grouping 
accosts m accordance with the present invention; 

Fig. 9 is an example of a graphical user interface that may be employed to 
program m accumulator in accordance with the present invention; 
5 Fig. 10 is a ihnerional block diagram of a method component in accordance with 

;ent ravetmon; 

Fig. 1 1 A is an example of a graphical user interface that may he employed to 
manage method operands in accordance with the present invention; 

Fig. 1 IB is an example of a graphical user interface that may he employed to 
10 - , v i Hwxdance with the present invention; 

Fig. 1 1C is an example of a graphical user interface that may be employed to 

i <! - J\ the present invention; 
Fig. 1 ID is an example of a graphical user interface that may be employed to 
associate a method with one or more accounts in accordance with the present invention; 
IS Fig. 12 is a functional block diagram of a calendar component in accordance with 

the present invention; 

Fig, 13 is an example of -a graphical user interface that may be employed to 
manage calendar characteristics in accordance with tire present invention; 

Fig. 14 is a functional block diagram of a calendar alignment system in 
20 accordance with lire present invention; 

Fig. 15 is a functional block representation of a system for deteramnng an impact 
associated with one or more calendar attributes in accordance with lite present invention; 

Fig. 16A is an example of a graphical user interface that may be employed to set 
calendar attributes in accordance with the present invention; 
25 Fig. 16.B is another view of the graphical user mteriace of Fig. 16A in which a 

selected group of days have been identified in accordance with the present invention; 

Fig. 1? is an example of a graphical user interface that may be employed to 
associate an event with one or more accounts in accordance with the present invention; 

Fig. 18 is a functional block diagram of a profde component in accordance with 
30 the ps'ssem v ; ' 
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Fig.. I9A is an example of a graphical user interface that may be employed to 

} , dance with the present invention; 
Fig, 19B is an example of a graphical user interface that may be employed to 
associate a profile attribute 'with a method in accordance with the present invention; 
S Fig, 20 is an example of a data structure for a profile in accordance with the 

present invention; 

Fig, 21 is an example of a graphical user interface that may be employed to 

nit area characteristics in accordance with die present invention; 
Fig. 22 is aii example of a graphical user interface that may be employed to 
■ o an characteristics in accordance with the present invention; 

Fig, 23 is an example of a graphical user interface that may be employed to view 
characteristics of defined key result areas and action plans in accordance with the present 
invention; 

Fig, 24 is a functional block representation of a work bench management system 
IS m accordance with the present invention; 

Fig. 2SA is an example of a graphical user interface that may be employed to 
manage work bench characteristics in accordance with the present invention; 

Fig. 23B is an example of a graphical user interface that may be employed to view 
work bench results in accordance with the present invention; 
20 Fig. 25C is an example of a graphical user interface that may he employed to 

define budgeting/forecasting parameters in accordance with the present invention; 

Fig, 26 is an example of an operating environment hi which a system in 
accordance widi the present invention may be implemented; 

Fig. 21 is a flow diagram illustrating a basic methodology to implement budgeting 
25 s • >(»• in accordance with &e present invention; 

Fig. 2H is a flow diagram illustrating a methodology for creating a database of 
records in a desired format in accordance with the present invention; 

Fig, 29 is a fiow diagram illustrating a part of the methodology of Fig. 28 in 
accordance; with the present invention; 
30 Fig. 30 is a flow diagram illustrating another part of the methodology of Fig, 28 m 

accordance with the present invention; 
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Figs, 31 is a flow diagram illustrating a methodology for generating a calendar in 
accordance with the present invention; 

Fig. 32 is a flow diagram illustrating a part of the methodology of Fig. 31 in 
- > !io < - , went invention; 

Fig. 33 is a Sow diagram illustrating a methodology for creating a key result area 
in accordance with the present invention; 

Fig. 34 is a flow diagram illustrating a methodology for creating an action plan in 
accordance with the present invention; and 

Fig. 35 is a flow diagram illustrating a methodology for -utilizing a work bench 
component in accordance with an aspect of the present invention. 

P^.ajlfed.DescriptioB of the In vention 

The present invention will now be described with reference to the drawings, 
wherein like reference numerals are used to refer to like elements throughout. The 
present in vention relates to a system and method to facilitate budgeting and/or 
forecasting. The present invention provides a powerful tool to enable management to 
plan, among other things, budgets, personnel, scheduling, product inventory, room prices., 
meal prices and discounts, in accordance with, an aspect of the present invention, 
planning may be done at any time period level, such as from a dally level to an annual 
level or greater, 

in the following description, for purposes of explanation, numerous specific 
details are set. forth in order to provide a thorough understanding of the present invention, 
it will be evident, to one skilled hi the art, however, that the present invention may be 
i ticed without these specific details. In other instances, well-known structures and 
devices axe shown in block diagram form in order to facilitate description of the present 
invention. While for purpose of illustration various aspects of the present invention are 
disclosed in the context of the hospitality industry, those skilled in the art will und« i a 
and appreciate that the various aspects have broader applications and that all such 
itions are contemplated as being within fee scope of the present invention. 
Various aspects of the present invention also have been organized under headings 
to facilitate an understanding of the principles of the present invention. The particular 
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d eet matter under each heading is for simplicity of explanation and is 
not < - s estrictive or limiting of the various aspects of the present invention, 

which are set forth in the appended claims. 

BASIC SYSTEM ARCHITECTURE 

Turning now to Fig. 1, a budget forecasting system 10 in accordance with an 
aspect of the present invention is illustrated. The system 10 includes a plurality of 
facility management systems (FMS) 12 that may communicate with a central server 14 
through a network infrastructure, such as the Internet 16. Each FMS 12 is operative to 

5 receive data .from a plurality of data collecting sources 20, 22, and 24. Hie data sources 
20. 22, and 24 may be operatively connected to the FMS 12 or the data may be 
communicated from the nodes to the FMS by other data transfer mechanisms (e.g., data 
may for a data source may 'be entered directly into the FMS). While, for purposes of 
illustration, three such data sources 20, 22, and 24 are shown in Fig. 1 as being associated 

10 with each FMS, it will he understood and appreciated by those skilled in the art mat any 
number of such data sources may be implemented in a system 1 0, in accordance with the 
present invention. It also is to be appreciated that the system 10 alternatively may be 
configured such that each data source communicates directly with the central server 14 
tor tcansmitttng and. receiving data, 

IS By way of example, the data source 20 may correspond to a business unit, such as 

a point of sale (POS) or another aspect of business operation. The data source 20 collects 
or accumulates data having a plurality of attributes indicative of different operational 
aspects associated with the respective business unit. Similarly, each of the data sources 
22 and 24 also may collect data that corresponds to one or more other aspects associated 

20 with operation at one or more business units. For example, in the hospitality industry, the 
data source 22 may collect data pertaining to facility reservations, banquets, sales and 
catering, telephone usage and call accounting, time keeping, payroll processing, accounts 
payable, general ledger, daily revenue recording, and/or any other internal system 
t . <hty or its operation. 

25 The data source 24 may collect data related to circumstances external to the 

internal operation at the facility. By way of example, the data source 24 may collect 
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inform i - to convention center activity, events at. local sporting and music 
venues, opinion polls, guest services scores, other nearby events and activities, and/or 
other information that may directly of indirectly affect the operation of the facility. The 
data source 24 further may collect environmental (e.g., weather, news, etc.) or economic 
5 information at a regional or local level that may have an impact on or be indicative of 
facility performance. Such externa] mformaiion may be created at each FMS 12 or be 
acquired from other service providers, such as the GDS center and STAR information. 

In the example of Fig. 1, the data sources 20, 22, and 24 feed into an associated 
FMS 12. Each FMS 12 may transmit the collected information to the central server 14 

10 via the internet 16. Use central server 14 processes the information received from each 
FMS 12 into consistent record formats and stores the consistent data in a database 26 in 
accordance with an aspect of the present invention. As described in greater detail below, 
die database 26 may be an Online Key Results Area Analysis (OKRAA) database, winch 
stores various data for a plurality of accounts of a chart of accounts (COA). Each account 

15 may include a pl urality of fields that contain different types of data indicative of various 
business aspects associated with each respective account. 

A computer 2$, such as a PC or workstation, may be operativeiy connectabie to 
the central server 14 for performing forecasting and budgeting in accordance with an 
aspect of the present, invention. The computer 28 includes a user input device 30 (e.g., 

20 keyboard mouse, etc.) through winch a user may interact with application software for 
entering parameters or constraints for controlling the budgeting and/or forecasting 
process. The application software may be resident on the server 14 and/or at the remote 
uter 28. It is lo be appreciated that, while the user input device 30 is illustrated as 
being associated with the remote computer 28, such a user input device may be associated 

25 with one of the FMS systems 12 or it may be connected to the sewer 14 directly or 
indirectly through a private network. 

DATABASE STRUCTURE 

'.fuming now to Fig, 2, a system 40 for creating a database 42 having consistent 
30 record formats in accordance with an aspect of foe pre* i ■ - strafed. A 
lit} of facility management systems (FMSs) 44, 46 and 48 collect data from several 

8 
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data sources, such as those described above with respect to Fig. 1 . A first translating 
component 50, 52, 54 pulls data ftom each respective FMS 44, 46, 48 into an associated 
s $ rtabase 56, 58, 60, Aliejiiatively, or additionally, each FMS 44, 46, 48 may 
push collected data to each respective first translating component 50, 52, 54. The first 
5 translating components 50, 52 and 54 translate the data collected from the respective 
FMS 44, 46 and 48 into FMS record formats and write file translated records to 
corresponding FMS SQL databases 56, 58 and 60. 

The data stored in FMS SQL databases 56, 58 and 60 is then pulled by a second 
translating component 62 that processes and stores selected portions of the FMS data m a 

SO central storage SQL database 64. The second translating component 62 may poll data 

hum the plurality of SQL databases 56, 58 mid 60, for example, on a predetermined basis 
or on an ad hoc basis. Alternatively, or additionally, records may he pushed from the 
FMS SQL databases 56, 58 and 60 to the second translating component 62. The second 
translating component 62 processes the records stored in the FMS SQL databases 56, 58 

1 5 and. 60 into a consistent predetermined format such as an OKRAA record format. As set 
forth below in Fig. 3, the second translating component 62 may access several 
stents (e.g., rule sets) to perform the translation. 
The second translating component 62 may store records in the centra! storage 
SQL database 64 in sets corresponding to their source FMS. For example, data set 66 

20 may contain only records polled and translated from FMS SQL database 1 56. Similarly, 
data set 68 may contain only records pulled and translated from FMS SQL database 2 58. 
Similarly, data set 70 may contain only records pulled and translated &om FMS SQL 
database a 60. These groupings facilitate creating the database 42 in accordance with an 
aspect of the present invention. 

25 An OKRAA generating component 72 may perform scheduled pulls of selected 

portions of the data fern the central storage SQL database 64 to populate the OKRAA 
database 42. The selected data may be associated with specific accounts, accumulators (as 
described Lei • (as described below) key results areas (as described below) 
and/or aeih m >lans (a < ascribed below) which, may facilitate budgeting and forecasting. 

30 - x • i may he ami tuonal database, is suitable for access from 

a plurality of software applications 64, 66 and 68. Developing new hospitality software 
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snd84 1 > > a from one or more diverse hospitality data 
ca > iuse the OKRAA database 42 stores I s onnationin 

OKRAA common record formate. 

By way of example, the application 80 may correspond to a budgeting program, 
while the application 82 may correspond to a forecasting application, and the application 
84 may correspond to a time keeping application. While, for purposes of illustration, 
three such software applications 80, 82 and 84 are shown in Fig. 2 associated with the 
OKRAA database 42, it will be understood and appreciated by those skilled in the art that 
a greater (or lesser) number of applications may be implemented in accordance with, the 
present invention. Also, while the applications are illustrated as being external to the 
OKRAA database 42, these and other applications could be integrated into the OKRAA 
database. 

The system 40 may also include an Online Analytical Processing (OLAP) 
, iug component 74 that pulls data from the OKRAA database 42 to create an 
OLAP database 76. Alternatively, or additionally, the data may be pushed to the OLAP 
generating component 74. It will be nnderstood and appreciated by those skilled in the 
ad that various deli very mechanisms may be used to present the data to the OLAP 
. ing component 74. The OLAP database 76 is organized using data storage 
techniques that facilitate online analytical processing, data mining and other such 
sophisticated data analysis technique The OLAP database 76 is organized in a manner 
that facilitates exporting data to other databases and applications. 

Fig. 3 Illustrates an example of a data translation system 90 that may be 
implemented in the database creation system 40 of Fig. 2 to translate a plurality of record 
formats 92, 94 and 96 from data sources, such as those associated with EMS 12 (Fig. 1), 
to a desired .format in accordance with an aspect of the present invention. The first 
translating component 50 may pull records from a plurality of data sources having a 
plurality of di verse record formats indicated in record format 1 92, record format 2 94, 
and record format n 96, The FMS rule set 98 contains rules corresponding to each record 
format that , 1 t Kzed by the first translating component 50 to convert received 
1 s t formal 100. The FMS rale set 98 is associated with the first 



10 



WO 02/13102 



translating component 50 to provide a mapping between the record formats 92, 94 and 96 

and the FMS record format 100. 

The first translating component 50 examines the records it receives and a source 

identification associated with those records. The first translating component 50, for 
s s Am and/or a source identifier associated wife die raw 

data to locate an appropriate rale in the FMS rale set 98. The first translating component 

SO then applies the appropriate rale to the record to convert it to the desired FMS record 

format 100. The FMS rule set 98 defines rules for how to translate any particular input 

record format from any data source associated with any particular FMS 12 in the system 
10 10 (Fig. l) into a desired FMS record format 100. The FMS rule set 98 may contain 

mapping tables, convssrsjon algorithms, concatenation routines, extraction routines and/or 

appending/deletion routines to implement the translation rales. 

By way of example, Record format 1, 92 may correspond to a room sold record 

format, such as may originate at a data source associate with FMS1 44 (Fig. 2). As 
I S shown in Table 1, die room sold record may contain fields storing information indicative 

of a date upon which the data was created, a booking date for a room, which room was 

booked and a room rate for that room. 



TABLE I 



Name 


Field 1 


Field 2 


Fields 


Field 4 


Room Sold 
Record 


Date Sold 


Booking Date 


RoomNnmber 


Room Rate 



The first translating component 50 also may pull records from other data sources, 
such as a restaurant. For example, record format 2 94 may correspond to a restaurant 
meal sold record format, such as may originate at another data source. As shown in Table 
XL a meal sold record format may contain fields storing information indicative of a date 
25 upon which the data was created, which appetizers were purchased, which entrees were 
parehased which drinks were purchased, which deserts were purchased, an amount for a 
hill and an amount for a tip. 
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Name 


Field 1 


Field 2 


Fields 


Field 4 


Field 5 


Field 6 


Field 7 


Meal 
Sold 
Record 


Date 
sold 


Appetiser 


Entree 


Drink 


Dessert 


Bill 

Amount 


Tip 

Amount 



In both of the above examples, the data could alternatively have been pushed from 
the respective data sources to the first translating component 50. It will be understood 

5 and appreciated by those skilled in the art that various delivery mechanisms could be used 
to present the data to the first translating component 50. It will further be appreciated that 

then - s also he utilized, in accordance with au aspect of fee present 

invention, to :har icteri % the various types of data that may be collected in connection 
with any aspect that may affect business operation. While, for purposes of illustration, 

1 o three such record formats 92, 94 and 96 are shown in Fig. 3, it will be understood and 
appreciated by those skilled in the art that a greater (or lesser) number of record formats 
may be translated in accordance with the present invention. 

Continuing with the above example of a room sold record and a meal sold record, 
several FMS records may he created. By way of example, each EMS record may contain 

1 5 fields concerning the date the data was created, the source identification from where the 
data cams, with what account that data is associated, and the raw data from the data 
source. An FMS record corresponding to. for example, a room sold record may contain a 
date field, a source identification field, and the raw data from the data source. The FMS 
record corresponding to the meal sold record may contain a date field, a source 

20 identification field, an account field, a sub account field, a minor account field, and the 
data specific to the data source. FMS records created from different data sources may be 
stored in different though consistent FMS record formats, such as those shown in Tabic 



in. 

TABLE III 



| Date 


Source ID 


CQA ID 


Raw Data Fl 


Raw Data F2 




Raw Data Fn 


Dl 


1 


1 


Room 3 


$125 






Dl 


1 


} 


Room 4 


$120 






02 




13 


Cheese stick 


Steak 




$3.50 


















2 


I. 


Shrimp 


Lobster 




$27.00 
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While ifee i pie shows ail the data field b 

net >d n ' insMon roles may involve different mappings. For 
example, on • for processing a record with seven fields that 

originated from a point of sale. After identifying which rales from the FMS rale set 98 
apply, by using tie source identifier and the account identifier, the first translating 
component 50 may apply the rules to the record. When applying the rales to the record, 
the first translating component 50 may copy the first field directly from the input record 
to the FMS record. The first translating component 50 may then combine the second and 
third fields from the input record into one field in the FMS record and may discard the 
fourth and fifth fields from the input record, The first translating component 50 may then 
perform a look up in a table based on the sixth field in the input record to create a field in 
the output record. The first translating component 50 may then apply an algorithm to Hie 
seventh field to produce a new number that will become a field in the output record. The 
first translating component 50 may then add a source identifier field and time and date 
stamp fields to complete the example translation. Such rules may vary depending on, for 
example, She format of the data obtained .from each data source and what information is 
desired and in what format it is to be stored. 

The second translating component 62 translates each FMS record format 100 into 
an OKRAA record format 102. The second translating component 02 may pull records 
from file FMS SQL databases 56, 58 and 60 (Fig. 2). Alternatively, or additionally, 
records may be pushed from the FMS SQL databases 56, 58 and 60 to the second 
translating component 62, 

An OKRAA role set 104 is associated with the second translating component 
The second translating component 62 may find a required mis in the OKRAA rale set 
104 based on a source identifier and an account identifier associated with each FMS 
record. Once the appropriate rales are found, they are appiied to the records from the 
FMS SQL databases 56, 58 and 60 to produce records in the desired OKRAA record 
format 102. The second translating component 62 may, for example, combine fields, 
copy fields, delete fields, perform look ups based on a field's value, apply an algorithm to 
a field and/or append additional fields to create an OKRAA record format 102 from ait 
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record format 100 according to rules found in the OKRAA rule set 102, Additional 
rules sets also may be provided to convert the FMS record format data to other OKRAA 
record formats. 

As mentioned above, the number and type of fields in the record formats 92, 94 
and 96 may vary both in the number of fields present, the type of information in the fields 
and in the information stored in each field. To accommodate the varying record formats 
92, 94 and 96, the OKRAA record format 102 includes a combination of base fields and 
variable fields that form an OKRAA record 108. The base fields may contain 
information associated with, for example, identifying a data source 1 1 0, identifying a 
transaction amount 1 1 2, identifying a currency type 1 1 4 and identifying a date 1 1 6. The 
OKRAA record format is extensible to include account fields containing information 
associated with, for example, identifying a site 1 18, identifying a department 120, 
identifying an account 122, identifying a sub account 124 and identifying a minor 
account 126, 

It v. A . Hcd so the art that the fores d i 

structure and system for collecting data represents but one example that may be 
accordance with the present invention. Odrer types of databases could he 
employed to store both collected and computed data for use in a system operating in 
accordance wife the present invention. 

Fig. 4 is functional block diagram illustrating a system. 1 50 in accordance with an 
aspect of fixe present invention. The system 150, which may run at the central server 14, 
» I ts a user interface 1.52 that is provided locally to a user. A user may interact with 
different aspects of the system 150 through the user interface 152 so as to perform 
budgeting, forecasting, trend analysis, business plaiunng, as well as comparative analyses 
o > e or more of the foregoing. 

The system 150 includes several operative components (or interactive tools) 160- 
174, which cooperate to provide desired functionality according to the stored data, such 
as data that may be have been collected and stored in an OKRAA database (historical and 
computed data) and other data mdicative of other factors that may provide some 
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quantitative and/or qualitative measure related to some aspect of business operations. 
Such other factors may include circumstances associated with a local economy, weather, 
competition, nearby attractions or sporting events, and/or any other situation or 
circumstance that might affect some aspect of a company or business. 

5 By way of example, the components may include a chart of accounts component 

160, a method component 162, a calendar component 164, a profile component 166, a 
key results area component 168, an action plan component 170, a work bench component 
172, and & report generating component 174. Collectively, the components 160-174 
define a set of rules (as may be configured by a user) that may be applied to the stored 

10 data 154 to provide an indication of one or more operating characteristics associated with 
a facility or a group of facilities. Exemplary aspects associated with each of these 
components are described below under corresponding headings. 

CHART OF ACCOUNTS 

15 The accounts for the system 150 are stored in a chart of accounts 160 (Fig. 4). In 

general, a chart of accounts is a systematic listing of all accounts used by a company. 
The chart of accounts 160 for the system 150 (Fig. 4) lists accounts that may be 
represented by an account data structure. Fig. 5 illustrates an example of an account data 
structure 228 in accordance with an aspect of the present invention. An account record in 

20 the OKRAA database record format may comprise one or more required fields and 
optional fields. In the example illustrated in Fig. 5, ten fields 232 are available as 
optional, flexibly programmable fields. Allowing user-programmable optional fields 232 
lc xibiiity to he able to- reconcile the diverse record formats found at the data 
sources into a common OKRAA record format 

25 In the example account data structure 228 illustrated in Fig. 5, a first field 

contains a chart of accounts identifier (COA J.D) 230. This field is a primary key for 
accessing an account record in a chart of accounts. The COA ID 230 also may be used 
as a key In other tables and databases to allow for cross referencing to the chart of 
accounts. 

30 The nex i 12, \v inch are identified as COA . COLx fields, where x 

ranges from 1 to 10, are optional flexibly defined fields. The fields 232 may contain 
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different types ofiafonaatlon for diiferent accounts. For example, in the room sold 
OKIiAA rec . Hscussed above, one of these flexibly defined fields could be used to 
store the room number and another flexibly defined field could be used to store the room 
rate, in the meal sold record described above, one flexibly defined field could store the 
appetizer purchased, one could store the entree purchased, one conld store tire drink 
purchased and smother could store the bill amount Additionally or alternatively, the 
flexibly defined fields may define level attributes for each COAJB within a hierarchy of 
accounts for a company or business. 

"flie account data structure 228 also includes a field labeled 
COA_CONCAT. VAL 234 thai .facilitates ihe concatenation ofaccotrate. By 
concatenating accounts, new and .more flexible billing and/or forecasting is facilitated. 
The account record format illustrated also contains housekeeping fields 236, 238, 240 and 
242 for determining who created or updated any particular record stored using the 
account data structure 228 as well as creation and update tiroes. 

In the example account data structure 228 illustrated, each attribute has a data type 
field 246, a size field 248, a reference field 250, a key indicator field 252, and a 
description field 254 associated with it. While, for purposes of illustration, each attribute 
has such associated data fields, it will be understood and appreciated by those skilled in 
the art that the account record may be configured to include a greater (or lesser) number 
of data fields associated wife each attribute in accordance with the present invention. It 
also is to be understood and appreciated by those skilled in the art that an account record 
may be configured to contain a greater (or lesser) number of fields in accordance with the 
present invention. 

Fig. 6 illustr ates an example of a hierarchy of accounts 268 in accordance wife an 
aspect of ihe present invention. A chart of accounts may store a collection of account 
identifying records, each of which identifying record contains an account level field, thus 
f aciiitatiag representing the hierarchy of accounts 268. 

The hierarchy 268 may start with a company 270 or other organizational unit. 
The company 270 may comprise a plurality of sites (e.g., physical locations) 272, 274 
and 276. A site 272 may, in turn, comprise a plurality of departments 280, 282 and 284. 
A department 280 may comprise a plurality of accounts 290, 292, 294. An account may 
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comprise a plurality of sub-accounts 300, 302 and 304. While, for purposes of 

stra evels of h c 1 ustrated in Fig. 6, it will be understood and 

appreciated by those skilled in the ail that a greater (or lesser) number of levels may be 
used m accordance with the present invention, 
5 By way of illustration, a company level ac-cmmt record may contain the following 

fields; a COAJD, a company identifier and a set of data fields, A site level account 
record may contain the following fields: a COAJD, a company identifier, a site identifier 
and a set of data fields. Similarly, a department level account record may contain the 
.following fields: a COAJD, a company identifier, a site identifier, a department 

1 0 identifier and a set of data fields. An account level account record may contain tire 
following fields: a COAJD, a company identifier, a site identifier, a department 
identifier, an account identifier and a set of data fields. A sub-account level account 
record may contain the following fields: a COA JD, a company identifier, a site 
identifier, a department identifier, an account identifier, a sub-account identifier and a set 

15 of data fields. The flexibly defined fields, as described in Fig. 5, may be used to 

implement these and other account record formats for records at different levels in the 
account hierarchy 268. 

Fig. ? illustrates an example of a graphical user interface (GUI) 310 that may be 
used to create an account entry in a chart of accounts in accordance with an aspect of the 

20 present invention. That is, die GUI may be employed to define the various account 

entities in the system, such as the various sites, departments, accounts, snb-acxxmnts and 
minor accounts described herein. 

The GUI 3 1 0 includes a display table 3 1 1 that contains hrforrnation about each 
account record in the chart of accounts. A key into the account entry shown on Fig. 7 is 

25 &e COAJD field 3 12, which is the chart of accounts identifier field. As mentioned 

above, the COAJD field 312 may also be used as a key into other tables, like an account 
table, where the record structure for an account reeord is stored. By rising the COAJD 
field 3 12 as a key in associated database tables, the structure for airy raw data may he 
obtained, < iing interrelation, translation and other processing. The table 

30 shown in Fig. ? includes four columns, namely, a COAJD column 31 2, a description 
column 3 14, an account level colmxm 316 and an account type column 318. While, for 
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purposes of illustration, Hie account data structure is illustrated m Fig. ? as a table, U will 
c a | i b> those skilled in the art that other data structures may be 

dized. i $ .i. in present invention, to characterize the various account 

attributes, 

The COAJD column 312, as described above, is the primary key and is used to 
uniquely ide d ascription of the account. The description column 314 is a text 
description of the account to which the record applies. The account level .column 3 1 6 
records at which level in the hierarchy of accounts 268 (Fig. 6) the entity being modeled 
by an account resides (e.g., is it a site, a department, an account, a sub-account,, etc.). The 
account type column 318 identifies which of several basic types of account the account 
represents. 

The GUI 310 may also include a user interface element 320, such as may include 
a dtop-dov, 5 leciing a desired account level from a predetermined list of 

i >nical user interface 310 displays the accounts in an order 
organi sed according to the selected account level. Addi tional action buttons 322 are 
provided for adding, deleting, saving, and/or canceling choices made concerning a 
selected account. 

Fig. 8 illustrates a system 350 for grouping selected accounts in accordance with 
one aspect of the present invention. An accumulator 358 may be employed to aggregate 
records from one or more accounts 352, 354 and 356. These accounts 352, 354 and 356, 
from which data will be extracted and aggregated, may be selected from a range of 
accounts. Such aggregations facilitate budgeting and forecasting. The aggregations are 
stored as accumulator data 360. For example, all the room sold records available for a 
plurality of accounts 352, 354 and 356 may be aggregated together by an accumulator 
358 to create one data repository 360 of room sold records to facilitate access to such 
data. For another example, selected accounts or all the accounts at one level of a 
hierarchy of accounts could be aggregated together to facilitate higher level budgeting 
and forecasting. An accumulator 358 may be described by its name, by the accounts 
from which i % & data, and the data feat it aggregates. In this way, the 
accumulator function may he employed to group any number of accounts; from as few as 
•a single account to as many as all the accounts. 
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\ i 9 illustrates an example of a GUI 370 that may be used to program an 
txiu x ie GUI 370 includes a user inierfa . . snieru 

an accumulator name and a user interface element 374 for entering a description of the 
accumulator. The GUI 370 also includes a user interface element 376 for entering an 

5 account level that can be selected, for example, ftom a predetermined set of choices 

displayed hi a drop-down menu. When selecting options like names and account levels, a 
user may employ interface buttons to add 392, delete 394, save 396 and cancel 398 
choices made concerning those options. The GUI 370 facilitates entering a sequence of 
accounts from which data may he aggregated. A sequence of accounts is identified by a 

JO sequence number 378, an account from number 380 and an account to number 382. 

When selecting the accounts from which data will be accumulated, the user has available 
buttons to add 384. delete 386, save 388, and cancel 390 choices to be included. 

METHODS 

15 Fig. 10 illustrates a functional block diagram of tbe method component (or 

module) 1 62 in accordance with an aspect of the present invention. The method 
component 162 includes a method manager 402 that may he associated with a user 
interface, through which a user may add, remove, or otherwise manipulate a method that 
may be implemented within the system 150 (Fig. 4), The method component 162 also 

2Q includes a methods interface 404 that may he employed to create one or more methods. 
Each method is combination of one or more expressions that has a unique name and 
application characteristics that determine how and to which date each respective method 
may be applied. Expressions may be combined, for example, via programmatic operators 
0F, WHEN, CASE, etc.) to define bow and under what circumstances the component 

25 expressions are to be utilized. The method data may be stored in a table or other data 
structure for identifying a list of defined methods that are available to the system. A 
method may also he utilized to retrieve desired data and/or to convert that data teto a 
useful representation, such as may correspond to budget data for a given account on one 
or more days. 

30 The method component 1 62 further includes an expressions interface 406 feat 

may be employed to create expressions which, in mm, may be used in one or more 
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i \xiG> pression, whit 1 i may include constants, operands, and/or operators, 

i (i % 2d and how it is to 'he processed -for each associated 

>e stored in data structure indicative of the available 
expressions for each method. An expression may contain an algorithm or stored 
procedure, such as in the form of a formula or expression, which may be applied to data 
stored in one or more records. Various operators may be utilized to combine operands in 
a desired way including, for example, arithmetic operators (e.g., 4, -, X, /, etc.), relational 
operators (e.g., <, >, « etc.), Boolean operators (e.g., NOT, OR, XOR, AND, etc.), and 
other logical operators. 

The method component 162 also includes an operand interface 408 that may be 
employed to create define segments of data that are to be processed or accumulated for 
use by the expressions interface to generate expressions. The operands may be global to 
the method ; sions so ihat a given operand may be applicable to numerous 

types of data. Each operand further may include attributes, which may define various 
characteristics of each respective operand. The data pulled from a database and utilized 
by an expression or m operand associated therewith may come, for example, from a 
single account record, from a range of account records, or from a set of account records. 

A method thus includes a plurality of attributes that may include a name and an 
expression, which, in turn, may include one or more operands. A method may be utilized 
to retrieve historical data and/or it may utilize data derived from one or more other 
methods, A method also may be programroatically linked to one or more accounts listed 
in the COA. Progrananatically linking a method to an account provides the benefit of 
automatically having the numbers or other logical results the method, produces available 
for other applications or methods. This automation facilitates budgeting and forecasting 
by making derived data concerning the hospitality industry readily available. 

By way of example, a method may pull data from database data fields into an 
active method and process selected data from the data fields with constant data fields 
defined in the method to produce a data item or result. Hie database data fields may 

>j example, to a bill amount and whether a desert was ordered. The constant 
data fields may, for example, identity a percentage representing a historical ratio of 
deserts purchased to entrees purchased and the desired percentage of deserts purchased to 
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entrees purchased. The deri ved data item, produced by the method applying its 
expre ssios 1 1 bs a number indicating whether a business unit 

associated with the data source supplying the database values is meeting or exceeding a 
desired desert to emme ratio. 

5 By way of further example, raw data may be collected concerning the number of 

rooms occupied at a hotel and the total revenue collected from selling those rooms. The 
two pieces of data may he stored in an FMS record. A method may be associated with an 
accouni(s) whose FMS record format includes those two fields. The method may retrieve 
those two pieces of information from a record for a specific date and produce a derived 

10 number, such as the average daily rate for that date. 

By way of further example, raw daia may also he collected concerning the number 
of rooms occupied at a hotel and the number of rooms vacant. These two pieces of data 
may be stored in an FMS record and translated into a desired record format (eng., and 
OKRAA record format). A method may be associated with an account that includes the 

15 identified two fields. The method may retrieve those two pieces of information from the 
records for a range of dates and produce a derived number, namely, the occupancy rate 
for that hotel. The occupancy rate may then, in turn, be used by a separate method that 
employs a constant to represent the labor needs per room and the derived occupancy rate 
to compute the forecasted dally labor needs for that hotel over each day in a selected date 

20 range. 

As set forth below, a method further may be associated with a Key Results Area 
(KRA), a profile, an action plan, or any other aspect of a hndgethig and/or forecasting 
process, m accordance with an aspect of the present invention. The associated meihod(s) 
may be applied to data, such as may be stored in the OKRAA database, to provide an 

25 impact value or other quantitative (or qualitative) representation associated with, an aspect 
of operation at a facility or group of facilities. 

Some methods may be predefined while others may be created by a user. Fig. 
1 1 A illustrates an example of an operand GUI 420 that may be employed to create an 
operand for use by an expression ia accordance with an aspect of the present invention. 

30 - st v o>_nients 422 and 424 for entering a name and a 

description of an operand, A drop down menu 426 may be employed to enter the type of 
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data thai may be defined by the operand (e.g., constants, currency, other data types data 
pulled from She database). An operand may be assigned to one or more CO As, such as by 
selecting a desired COA (e.g., by identifying a COAJD) from a drop down menu 428 or 
selecting a desired accumulator from another drop down menu 430. 

5 He GUI 420 also includes user interface elements 432 and 434 for respectively 

entering fee type of currency (e.g, f U.S. dollars, Canadian dollars, Mexican Pesos, etc.) 
and the data source or budget to which tire operand may be applied. A list of die 
available operands is shown in a display portion 436 of the GUI 420. Action buttons 438 
. also are provided to save, remove, or clear fields associated with a corresponding 

10 operand. 

Fig. ! IB illustrates an expressions GUI 440 entering expression data, which may 
include constant data values, database lookup variables, arithmetic operators, and logical 
operators. The GUI 440 includes user interface elements 442 and 444 for entering a 
name and a description of an expression. A list of available operands are provided in an 

IS interactive display 446 from which operands may be selected for use in an expression. 
Operands may be combined by selectively employing operators, which may be 
implemented via user interface elements 448 (arithmetic operators), 450 (relational 
operators), 4S2 (conditional operators), and 454 (logical operators). The resulting 
expression is shown ; n an ex 

20 An example of a method GUI 460 is shown in Fig. i 1C, such may he employed to 

create a method fixma a list of available expressions. A method is assigned a name and a 
description by entering desired information at user interface elements 464 and 466, 
respectively. Various expressions may be combined to construct a method by arranging 
expressions with programmatic operators provided by user interface elements 468. The 

25 resulting method is displayed in a display portion 470. The constructed method may be 
generated by activating user interface element 472, which ^grammatically combines the 
associated data fields to facilitate its application to selected data. Other action buttons 
474 may be utilized to save or remove methods as well as to clear the fields of a currently 
displayed method. 

30 A method may be linked to one or more selected accounts by employing a 

method-account GUI 476, such as shown in Fig. HD. The GUI includes user interface 
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fronts 4~ and A * for entering an account range for which a user desires to assign one 
or more inethods(&g., based on the CQAJD). Another user interface element 482 is 
provided for selecting the type of data (e.g., currency type or other units) of the selected 
account to which a. method is to he applied. Examples of the type of data (or units) 
include U.S. dollars, rooms, sales, tips, etc. The available methods are listed in an 
selectable method display 484. The available methods for each account may assigned to 
one or more types of method for each respective account, such as by employing user 
interface elements 486. One type of method is a reference method 488 and other type of 
method is a historical method 490. 

The result s of the two types of methods, after being applied to die stored data, 
provides a comparison in the work bench component, as described herein. The historical 
method 490 provides a base method, such as may provide base budget information upon 
applying a selected method that, performs a historical analysis (e.g., a trend analysis) on 
the stored data. The reference methods provide results that may he compared with other 
results to gauge the level of success or failure of that result 

CALENDARS 

Fig. 12 illustrates a functional representation of the calendar component 164 in 
accordance with an aspect of the present invention. The calendar component 164 
typically is employed during system setup via a calendar set up user interface 500 for 
defining one or more calendars that may be utilized in forecasting and/or budgeting 
processes and to generate corresponding reports. Each calendar has several 
characteristics, which may include the type of calendar, the period of the calendar, and 
calendar attributes (if any) within the defined period. Bach characteristic may be stored 
in a corresponding data structure 502, 504 and 506 associated with the user interface 500. 

By way of example, a user may employ the user interface 500 to create new types 
of calendars that are stored in the system database, although commonly used calendar 
types also may he predefined. For each calendar type, a user may specify the number of 
calendar periods associated with that type of calendar. Examples of the types of 
calendars include: daily, weekly, monthly, quarterly, semi-annually, annually, budget 
calendar, a forecast calendar, seasonal calendars, etc. A monthly calendar type may have 
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12 equal periods m a year and a daily calendar typically has 365 equal periods m a yeas-. 
A seasonal calendar may be user-defined periods, which may be variable for each 
r $ further may include a field that defines the periods in each 
respective type of calendar including its stalling day and ending da ; GUIs may 

5 he provided to define the types of calendars and the period of each calendar. 

Fig. 13 illustrates an example of a GUI 510 that may be employed to generate 
and/or modify a calendar- in accordance with an aspect of the present invention. The 
calendar GUI 510, for example, forms pat of die user interface 500 (Fig. 12). The 
calendar GUI 510 may include a calendar site user interface element 512 for specifying 
10 with which site (or sites) the calendar may be utilized. The calendar GUI 530 also 
les other user interface elements 512 s 514, 516, 518, and 520 for respectively 
specifying a name for the calendar, a description of the calendar, the type of the calendar, 
and a date range for the calendar. A generate calendar button 522 also is provided to 
. e- Oar for the specified range. Other action buttons 530 may be provided to 
15 add a calendar to be generated, delete an existing calendar, save a generated calendar 
and/or cancel a previous operation. The various characteristics associated with the 
calendar may be shown on a corresponding display 532 of the calendar GUI 5.10. 

Once the calendar types and periods have been defined, a user may then set align 
the historical calendars with each calendar year for which budgeting and/or force. ; »• . 
20 may be performed. Attributes associated with selected days in each calendar, such as by 
specifying desired characteristics about the calendar, also may be selected. The calendar 
may then be generated and stored as a table thai includes fields identifying fee specified 
characteristics of the respective calendar. 

As mentioned above, data may be stored in the QKRAA database organized by 
day for a plurality of calendar years. Information about various aspects of facility 
stared in predefined fields associated with each day of each calendar year. 

such as sendee oriented businesses, fas slity operation and 
30 ] » n - may be impacted differently depending on which da-* s 

well as based on external factors that may draw potential customers into a- given 
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v v ♦ . * 5 :'«>v.rent account attributes for a restaurant at a facility 
ma.) be impacted ' -luring certain week days relative to one or both days in a 

particular weekend. Moreover, the level of activity may further vary depending on when 
a particular holiday occurs or when special events or activities may take place at the 

5 facility or at locations near the facility. 

Referring now to Fig. I4A, the calendar component 164 (Fig. 4) may include a 
calendar alignment system 540, which aligns or links historical calendars based on 
calendar set up data 542, in accordance with an aspect of the present invention. The 
calendar alignment system 540 generates calendar alignment data 544 for each calendar 

SO in the historical database. The calendar alignment data 544, which may be stored at the 
central server 14 (Fig, 1), provides a day-to-day alignment between each day in a user- 
defined calendar and each day in the historical database. This enables the system 150 
(Fig, 4} to budget/forecast a day-to-day (or other specified time base) impact on one or 
more account attributes of a COA for a facility or for a. selected aspect of facility 

55 operation. 

la particular, the calendar set up data 542 is converted into data 546 identifying 
the starting day parameters tor a calendar year to be processed, such as may be set by a 
user via she user interface 500 (Fig. 12), A calendar alignment function 548 receives the 
data identifying starling day of the calendar year. The calendar alignment function 548 is 

20 interfaced with a historical database 550 containing historical data for a plurality of prior 
calendar year's 552, 554, and 556, the extent of which may he defined by a user. The 
calendar- alignment function 548 employs tire starting day data to locate a day in each 
calendar 552, 554, 556 of the stored data 550 thai matches the starting day of the calendar 
period and stores fee corresponding data. Once the starting days are aligned io fee same 

25 day of the year, the remaining days in each historical calendar fall into place. The stored 
data provides a day-to-day mapping between each day of the year in the defined calendar 
p« od -<. p siding day in the stored historical data 550. As a result, each defined 

x s <. s.<n year (or years) may be mapped to a corresponding period in 
iars so that each day is aligned with the same day of the week and 

30 within the same week of the calendar year as its corresponding day of the user-defined 
calendar, 
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For example, May 1 in each of the years 1995 through 2000 occurs on a different 
day of the week, as indicated in Table IV. As mentioned above, op< i tsti 

so certain industries [e.g., the hospitality industry) may be more dependent on fee day of 
the week than the date. Therefore, if Saturday, May 1, 2000, is tire starring date of a user- 
- lar, the calendar alignment function 548 is programmed and/or configured 
to link each twenty-third Saturday of each other calendar year in the stored data, such as 
illustrated in Table Y. The calendar alignment function 548, in turn, creates 
corresponding historical time periods in each calendar year that include the same day of 
the week and year as its respective starting date. As a result, fee alignment data may 
include alignment criteria indicating a starting day in each calendar year that is the first 
day of a calendar period, for each user-defined calendar. The alignment data also may 
parameters indicating an ending day and/or the duration of the respecti ve calendar period. 



TABLE IV 


DAY 


MONTH 


DATE 


{ \R 


t ,u v 


May 


1 


1999 


Friday 


May 


1 


1998 1 


Thursday 


May 


1 


1997 


Wednesday 


May 


I 


1996 


Tuesday 


May 


1 


1995 


TABLE V 


DAY 


MONTH 


DATE 


YEAR 


Saturday 


May 


1 


1999 


Sa 


May 




1998 


Saturday 


May 


3 


1997 


: :::!■.!.;. 


May 


4 


1996 


Saturday 


May 


6 


1995 



Referring back to Fig. 12, another feature of the calendar component 164 relates 
to characterizing calendar attributes. Calendar attributes (or events) correspond to 
various types of days, such as holidays, events (eg., sporting events, festivals, concerts, 
etc.), conventions (e.g., held at the facility or at nearby venues), renovations and other 
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types of days (e.g., attractions, weather, news, etc.) that may affect operating 
siness ovu a period of one or more days. One or more aspects of 
? , accounts iron* the COA) may be designated for each calendar 
attribute m each usernfeilned calendar. The accounts may he designated by a user 
according to the type of day and/or which specific day it is (e.g.. Is it Super Bowl 
Sunday?, Independence day?, J®ez. Pest weekend?, etc.). More than event may occur on a 
; ; r. •: 'he \ cor {e.g., overlapping special days) and/or more than one account may 
be designated for each calendar event. 'Hie designated accounts are analyzed, for 
pie, by a method that applies the designated accounts to corresponding days in the 
stored data, which may include historical data and computed data, to determine 
{quantitatively and/or qualitatively) an expected level of impact associated wife each 
designated account for each event in the selected calendar- period. 

Fig. 15 illustrates a functional block representation of a system 560 for 
determining an impact, associated with one or more calendar events in accordance with an 
si t of the present invention. The system 560 includes a user interface 562 feat 
receives calendar attribute data 564, which may include an identifier for each event and 
mfdnnatioK i < cl mated account. An attribute method (or function) 566 
ilendar attribute data 564 to stored data 568 that includes historical data and 
.computed data for a plurality of calendar years 570, 572, and 574 (e.g., stored in fee 
OK.RAA database) to determine what impact (if any) may be expected for each 
designated account on each day corresponding to the selected calendar event. The impact 
for each designated account for each identified day may be provided as attribute impact 
data 576 that is mapped to its associated date in the budget/forecast calendar. By way of 
example, die system may automatically create a KRA for the determined impact for each 
designated account associated with the selected event The impact value may, in turn, be 
employed to adjust budget/forecast data accordingly. An impact value may be 
determined, automatically after an identified day/event and its account, attributes are 
designated for a period of one or more days. 

An example of calendar attribute data that may be entered is illustrated in Table 
VX The calendar attribute data may include a name for identifying the particular event 
(e.g., event holiday, convention, renovation, etc.), which is employed by the attribute 
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! 566 to beats like days in the historical data. 568. The identified day may 
• .pond to one or more days, as specified by the date or dale? e -red 1 1 »« user for 
the respective day. One or more account attributes (Attribute I to Attribute K) may be 
designated for each day, which a user may enter an expeeted'estimated value. The 
estimated value may be based on a historical analysis or on mfbnnatkm provided by an 
event coordinator. The estimated value provides information that helps the user better 
determine which account attributes should be designated for a particular event. 



TABLE VI 



- ieid Sana 


Description/Function ality 


Hams 


Name of selected day (e.g., event) 
needed to mark the dates associated 
with them 


Month 


Month in which the attribute is to be 
marked 


Year 


Year in which the attribute is to be 
marked. 


From Date 


The From date to be selected to mark 
a block of Attributes 


To Date 


The To date to be selected to mark a 
block of Attributes 


Attribute 1 


is itnt of fa 






Attribute N 


Name of Nth attribute 



Figs. 16A and 16B illustrate an example of a GUI 580 that may be employed, in 
accordance with an aspect of the present invention, to define calendar attributes, such as 
may correspond to an event, holiday convention, renovation, etc. In the illustrated 
example, fields 582 and 584, which include area attendance and room nights, have been 
sd for holidays. A user enters an expected value for each, field indicative of an 
estimated and/or expected number based on, for example, an event coordinator or based 
on some report. As a result, each holiday day entered as an identified day may he 
assigned tor the area attendance and room nights to help a user determine what accounts 
may be impacted by the event on tire appropriate days. While in this example, fields are 
5 ned for a type of day, those skilled in the art will understand and appreciate that 
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attributes eon ( i ;d as a function of the particular idem « f., by holiday 

name). 

in Pig. 16 A, a user may select an INDIVIDUAL DAY tab 586 to eater calendar 
attribute data for a single day, a MARK GROUP tab 588 to enter calendar attribute data 
lor a group of days, and/or a VIEW tab 590 to view attribute data previously entered and 
fee impact values associated with each such attribute. Pull down menus 55)2, 594, and 
§96 also are provided so thai a user may select a type of day, select a month and select a 
year. A display table 598 associated with the GUI 580 displays calendar details 
associated with each attribute in the selected range based on the user entered information. 
The display table 598 may, for example include fields for the date of the identified day, 
fee name of fee identified day, a description of each identified day, and fields identifying 
expected numbers for fields 582 and 584 associated wife each identified day. 

M Fig, 16B, for example, a group of days 600 has been selected or identified, such 
as via a user input device (e.g. , a mouse or keyboard). The identified days are listed in 
the display table 598 together with estimates for selected parameters. The area 
attendance field 582 is provided a value indicative of fee number of persons are expected 
disc to fee event on the identified day and the room nights field 584 is provided a value 
indicative of how many rooms/night are expected due to the event on each identified day. 

Alter an event has been defined, each event may be associated with one or more 
account attributes, which may be selected by a user. .Fig. 17 illustrates an example of a 
GUI 602 may be employed to selectively associate events to accounts in accordance with 
an aspect of fee present invention. The GUI includes user interface elements 604 for 
entering a range of one or more accounts to which an event is to he assigned. Another 
user interlace element 606, which may include a drop down menu, is utilized to designate 
fee type of unit for which an impact is to be derived A list of events is provided in a 
user-selectable display portion 608, An event may he mapped between fee display 
portion 608 and a selected events display portion 609 of fee GUI 602 via mapping 
interface elements 610. The event mappings may be saved, modified, deleted by 
m plo] we, act on buttons of the GUI 602. 

As mentioned above, an impact is determined for each account associated wife 
each event based on an evaluation of each respective account for at least one 
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cotr^poiidiag day in the historical data. By way of example, attributes may correspond 
to one or more accounts, such as the number of rooms sold, the number of covers at a 
hotel restaurant, labor hours for one or more aspects of facility operation, or any other 
ifiable operating characteristics of an business for which historical data has been 
stored, 

tig back to Fig. IS, for example, the attribute method 566 may access 
actual data for the most recent year (&g., CALENDAR YEAR. 1) 570 that includes one or 
more days matching the event, such as by attribute name, description, and/or other 
characteristics associated wife die event If the identified day is located in the 
CALENDAR YEAR 1 570, the method 566 then searches tire- next preceding year, 
CALENDAR YEAR 2, 572 to see if the identified event also exists in that year. For an 
annual event or holiday, it may be desirable to compare account data from the two most 
recent years in which die event occurred. 

The designated account data for the identified event in each of the calendar years 
570 and 572 may be correlated with respect to the same business unit (e.g., a hotel, a 

irani, cleaning staff, etc.) at the same facility. Alternatively or additionally, account 
data for the identified event may be con-elated with respect to data associated with, a 

rent operating unit at the same or different facilities having data for each of the 
designated attributes. For example, if die calendar event is not located in the historical 

, c <^ with the same site, the attribute method of die system may search for the 
same or similar events at other sites based on the attribute data torn which an impact 
value for each designated account may be determined. 

The attribute method 566 compares the value of each designated attribute in the 
two calendar years 570 and 572 for each identified event. The attribute method 566, in 
turn, provides impact data having a value indicative of an impact that the identified event 
{e.g., an event, holiday convention, renovation, etc.) had on each designated account in 
the calendar attribute data $64. This comparative analysis and impact determination may 
be applied to each identified event for each user-defined calendar. 

By way of example, if the identified day is a holiday and a selected attribute is 
room nights, the impact data for the room-nights attribute may provide a value indicative, 
of an increase or decrease (or no change) in rooms sold each nig! I W ~ alendar year 1 
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x ) fee same identified day in Calendar Year 2. The impact value eeuM 
correspond to a number or roor Idanc or a percentage of change. 

Those skilled in the art will understand and appreciate feat any number of account 

ates may- be designated in connection with an identified event or days associated 
with the event to derive desired impact data. The attributes for a particular type of event 
may be predefined, such as based on an analysis of stored data, or one or more attributes 
may be selected by a user. In accordance with an aspect of (he present invention, as set 
forth in greater detail below, more, than one feature or method (e.g., calendar days, ICR As, 

e> » don plans, etc.), may impact the same attribute(s) over a given period of time, 
so that the total impact on each such attribute on each day over the given time period may 

jpond to an aggregation of impact values for each respective day in the calendar 
period. 

PMMLES 

As shown in Fig. 4, the system 150 also includes a profile component J 66 that 
facilitates evaluating what internal and/or external factors may affect one or more aspect 
of a budget, forecast, business plan, etc in accordance with an aspect of the present 
in vention. Fig. 18 is a junctional block diagram of the profile component 166 illustrating 
an inteixdatlonsbip between profile-related data in accordance with an aspect of the 
present mvenfion. The profile component 166 includes a profile manager 610, which 
may be associated with a user interface 612 to facilitate creation and modification of 
profiles. Generally speaking, a profile is a data structure that contains a data set 
attributes) that models selected internal and/or external factors that may impact one or 
more operating characteristics {e.g., accounts of the COA) of a business. The attributes 
of a profile are selected so that one or more desired results or objectives are ascertainable 
^ irons 

The profile component 166 also may include a profile type manager 614, which 
may include a user interface, for entering and storing data associated with profile 
attributes for each type of profile as well as an indication whether each such attribute is a 
static or time -based attribute. The attributes for each type of profile may be stored in a 
profile attribute table 61 6. Attributes may be predefined for each type of profile, 
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although attributes (or attribute characteristics) also could be defined by a user during 
creation or modification of a profile. 

Some attri t ■ a profile may be static attributes, which nstant over 

time, while other attributes may be time-based attributes that may vary as a function of 
time. A riser may select which attributes are to be static arid which are to he time-based,, 
such as through an appropriate user interface component Each profile may store values 
tor its attributes in a corresponding attribute tabic, indicated at 616 and 61 8, although 
profiles also could be stored as other data structures in accordance with an aspect of the 
present invention. 

As set forth below, one or more KRAs or action plans may be created for a profile 
based on the attributes of the associated profile. Additionally or alternatively, one or 
more action plans may he created for each KRA to achieve an objective associated with 
the KRA and to identify an impact associated with carrying out fee objective. An impact 
for one or more accounts of the COA may be determined based on each KRA and/or 
action plan associated with a profile. Moreover, a method may be developed based on a 
profile to further quantify an impact on one or more aspects of the brKlgeting/foreeasting 
process. Such methods may be Independent or associated with a KRA and/or an action 
plan. 

An example of profile attribute data that may be utilized in accordance with an 
aspect of the present invention is illustrated in Table VII. Briefly stated, each profile 
includes a name that identifies the profile (e.g., operating as a key). A type also may be 
defined for a profile, which type may determine some or ail of Hie attributes that may be 
employed to define the profile. The predefined attributes for each type of profile may for 
example be stored in connection with the profile attributes table 618 of Fig. 18. A profile 
aiso may be assigned a date range (one or more days) and a site ID for which fee profile 
is to be applicable. Additionally, a user (e.g., a department head, manager, etc.) may 
enter values for each attribute in the profile. A user may enter the attributes and values 
for the attributes of a particular profile or the information may be retrieved from a 
eommereialiy available database. One such database is the STAR™ database, which is 
commercially available .from Smith Travel Research of Hendersonviile, Tennessee. As 
mentioned above, some of the attributes may be static and others may vary over time. 
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Another a s ofile is a SWOT .field with which a user may characterize the 

v em th « opportunities, and Threats associated with a particular profile. 

The SWOT data may he based on a user's own experience or based on publicly available 
( > rs 



TABLE VII 



Field 


Description 


v a nc 


The name of die profile 


Profile Type 


Hie type of the profile {e.g. attraction, event, 
competition, etc.) 


inscription 


The description of the named profil< 


< x my: 


The date range of the profile 


Distance 


The distance of the profile form the 
site/property 


SWOT 


The 'Strength' , Weakm.s~ > > >> i 
'Threats' a particular 'profile type* may possess 


SWOT Pi:-:.;:; i; 


The description of the 'SWOT* 


Attribute Name 


Ihe ust identifying all attributes of a particular 
profile (e.g., Location, Traffic 


- * Value 


t t > > ' 3 I * \ » 


Site ID 


attribute 


Time-based 
attributes 


+ « na nit a tin h il ste's 
month wise for the budget year (BY), the 
previous year(BY- 0 and the yeas- prior to 
fhatCBY-2) 



Fig. 19 A illustrates an example of a GUI 622 (illustrated as naming within an 
Internet browser) that may be employed to create and/or modify a profile in accordance 
with an aspect of the present invention. The GUI 622 incl udes, for example, several user 
interface elements in which a user enters appropriate information associated with a profile 
being created. The user interface elements may correspond to ihe fields identified in 
Table VII above. In particular, the GUI 622 includes a user interlace demen t 624 for 
entering the name of the profile. Pull down menus 626 and 628 also are associated with 
the profile type field and fee SWOT field, respectively, which a user may employ to 
select from among several predefined profile characteristics. 
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The GUI 622 also includes actios buttons 630 with which a user may perform 
selected ope? m ng a profile. For example, a user amy add a sew profile, edit 

an existing profile, delete a stored profile, save the currently entered profile 
characteristics and update the profile table in tire database, and/or cancel the last 

5 operation peribrmecl Another action button 632 is provided to .link a profile to one or 
more KRAs that may be utilized to achieve a desired result concerning one or more 
n >s s ued with the respective profile. 

The GUI 622 further includes a user-interface element 634 for static profile 
attributes and another user-interface element 636 for time-based profile attributes. The 

10 user-interface elements 634 and 636 may be employed to enter and store attributes and 
values for such attributes. The user-interface element 636 further may include a 
selection indicator 63S that may be employed to select a desired time base. For 
example, the time-based attributes may be entered over a time base covering die most 
recent three years, for up to two years ago, for up to one year ago, or a time period 

35 including only &e current year. Values tor each of the time-based attributes may, in 
turn, be entered for an incremental part of the selected time base <<?.&, monthly, semi- 
monthly, quarterly, etc.). It is to be appreciated, however, that other time bases and 
incremental parts thereof also could be utilized to create a profile in accordance wi th m 
aspect of the present in vention. A me&od also may be associated with each time-based 

20 attribute for deriving the attribute values for each interval of the selected time base, 

Fig. 198 illustrates an example of GUI. 640 that may be employed to associate a 
profile attribute with a method. The GUI 640 includes a user interface element 642 for 
identifying each attribute for winch a method is to be assigned, A method is selected is 
from an interactive list 643 of available methods, such as by activation of an appropriate 

25 user interface element 644. The user interface element 644 is operative to select and 

deselect a method for the profile identified in the user interface element 642. A selected 
method is displayed in a selected method field 646 of the GUI 640. The association 
between methods and profile attributes may be saved via action buttons 648. 

Fig. 20 illustrates an example of a profile data structure 650 for a competition 

30 profile, such as may be generated with the GUI 622 of Fig. 19A< Profile details 652 may 
be entered into a profile to define items, such as, for example, a profile's name (New 
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Supply), a profiled property's type (Competition), a description of the profiled entity or 
situation (Hotel 1), a date range over which the facility is profiled, the distance from the 
profiled site to the potentially affected site, a Sfiengt5vWeakness/Oppoj1imit>'/Target. 
(SWOT) designator (T-threai) and SWOT description (dilate demand). The illustrated 
5 example includes a plurality of time-based attributes 654, for which values ate to he 
provided (e.g., based on application of corresponding methods) for the three preceding 
years <Yr~3, Yx-2, and Yr-1) 656, 658, and 659. The attributes, which are listed for 
purposes of illustration, indicate several data points that may be useful in evaluating 
competition relative to the identified business (Hotel I). It will be understood and 
10 appreciated by those skilled in the art that a greater (or lesser) -number of data points may 
be utilized in accordance with the present invention. 

KB) RESULT AREAS 

Referring back to Fig. 4, another aspect of the system is a key results area (KRA) 
15 component 168 for, in accordance with an aspect of the present invention, capturing and 
quantifying an impact on one or more selected budget entities (or accounts) of the COA, 
A KRA may be an independent entity for characterizing a desired result or impact on a 
selected COA item. Alternatively or additionally, a KRA may be defined as a result that 
may be desired to influence one or more account attributes associated with a predefined 
20 profile, such as shown and described with respect to Figs. 18-20. As mentioned above 
some KRAs may be generated by the system, such as for designated accounts associated 
with identified calendar attributes, A KRA also may be associated with one or more 
action plans, as described below, which establishes a cost or expense that may be 
associated with achieving the result defined by the KRA. Each KRA may he assigned an 
25 impact value for the account attribute associated with each respective KRA, which may 
further be provided as a percentage of a value derived by a selected method. 

Table VW illustrates an example of data that may be entered as part of a KRA. 
The characteristics of a. KRA may be better appreciated with reference to Fig. 21 . 

30 
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TABLE VTA 



Field ^atae 


Description/Functionality 




Thenar of the KRA 


s Name 


The profile name that may be associated with, the 
"toT^ ~T- F*T i' r """f — ^sr ~~ 


Description 


> j hi oi 'the |ku Ucuid » * 


Accoum Vrom 


! 1 " i 1 ( * I 




The ending 'a oant (CO A) ?,v h 


Accumulator 


The user can either select Account From and 
Account To or an Accumulator thai has been 
ociined m the system 


From date 


The starting date for the KRA 




The ending date foi the KRA 


Imoaei Type 


The type of impact -percent a tcYj ue 


Method 


la case of a percentage type of impact, a user may 
select a method to apply for that impact 


Impact % 


The value of impact in percentage terms 


Impact Value 


The absolute value of the impact 


Objective 


• i. u -defined objective o, « 



Fig. 21 illustrates an example of a GUI 660 that may be employed, in accordance 
with an aspect, of the present invention, for defining characteristics of a KRA. Briefly 
stated, each KRA. is provided a name, such as may be entered at a user interface element 
66.2, The user Interface element 662 may include a drop-down menu for displaying a list 
of predefined KRAs. Another user interface element 664 may be employed to .link the 
named KRA to a selected one of a plurality of predefined profiles. A user also may enter 
a description of the named KRA. as well as an objective that the user may intend to 
achieve in respective input fields 666 and 668. 

Additionally, the system 150 (Fig, 4) may be programmed and/or configured to 
retrieve a list of one or more KRAs based on stored KRA data, from winch a user may 
select ail associated KRA that might better characterize a desired result For example, the 
system may store KRA data, including a KRA name, description, and/or other associated 
characteristics for each created KRA. The system also may store data indicative of the 
actual impact realized in connection with each KRA. When a user employs the GUI 660 
to create a new KRA, a search thus may be performed to locate related KRAs (from none 
to any number) from the stored KRA data. The related KRAs may be retrieved, for 
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example, based on the name, description and/or any other attribute of the KRA being 
• d list of the related KRAs provides the user with a choice of 
applying the new KRA the user has created (or is in the process of creating) or applying 
one of the related KRAs. The list of related KRAs further may include one or more 
system generated KRAs having computed impact values, such as an impact percentage. 
A computed impact value may be determined as a function of the actual results realized 
for a related stored KRA in one year relative to the actual results of fee same (or 
different) KRA in a different year, such as a preceding year. The user thus may select 
(e.g., via a suitable user input device) one of the retrieved KRAs or utilize the KRA 
created by the user or modify the user-created KRA, such as baaed on information 
associate h? the retrieve 

As mentioned above, a KRA may apply to one or more accounts of fee system 
COA over a selected date range. In this regard, the KRA GUI 660 also includes user 
interface elements 670, 672, 674, and 676 for entering a range of one or more accounts, a 
date range, as well as a drop-down menu 678 for entering a selected accumulator name. 
As mentioned above, an accumulator is name associated with a selected group of one or 
more accounts in fee COA, which might be further limited to a selected account level 

The KRA GUI 660 may further include an impact user-interface element 680, 
wife which a user may select the type of impact (percentage or absolute value) as well as 
a numerical impact number associated with the selected type of impact. The impact user- 
interface element 680 also includes a method selection user interface element 682 for 
linking a method to the identified KRA in accordance wife an aspect of the present 
invention. 

As described above, a KRA may be linked to a predefined method that is to be 
applied to fee selected accounts) to derive an impact based on fee data processed by fee 
. hod, such as based on budget parameters in fee hudgefeig/fereeastmg process (e.g., 
date range, account range, etc.), The method selection user interface element 682 may 
include a drop down menu listing fee available methods thai are applicable based on how 
the accounts have been selected. For example, some methods ma) < k abb to & 

-\ cc< ot, other methods may be applicable to range of accounts, and other methods 
may fee applicable to a set of accounts, such as may be defined by an accumulator. In this 
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' )- < : > •"* » d for a particular KRA attribute (e.g.» an account of 

s < ; < - hod .i derive value(s) associated with one or nrore other to 

which the impact percentage is applied to compute the impact value. 

By way of example, a method {e.g., a maximum rooms sold method for a hotel) 
may be applied to the historical data for the selected accounts (elements 670, 672, 678} to 
determine, for example, the maximum number of rooms sold in the date range indicated 
at 674 and 676.. The impact percentage may, in turn, be applied to the numerical result 
derived by the method to provide a corresponding impact value for the associated KRA. 
Moreover, a user may modify the KRA impact percentage and/or the method applied; 
such as via the GUI 660, which, in tun), may result in a corresponding update in the 
fissoclsted impact value. 

The GUI 660 also includes action buttons 684 that may be activated or selected to 
i vv;<A -An c exist k. '. delete an existing KRA, save a KRA to the 
c I a previous operation, and/or to sort through stored KRAs. Hie 
GUI 660 also may include action buttons 686 and 688 that provide links to a profile 
u * and to an action plan manager. The buttons 6S6 and 6B8 may provide a list of 
i & and action plans associated with the corresponding KRA, so as to facilitate 
coordination between a KRA and one or more profiles and/or action plans. 

A CTION PLAN 

With reference back to Fig. 4, the system 150 includes an action plan component 
1 70 through which a user may implement and/or manipulate one or more action plans in 
accordance with an aspect of the present invention. An action plan may be utilized to 
budget, forecast, and/or plan expenses that may he required to achieve a business 
-<v, e, such as budget revenue targets for one or more selected account areas. By way 
of example, an action plan enables a user to specify a time frame in which such expenses 
may he incurred, where in the COA such expenses may be incurred, and by whom (eg,, 
which empioyee(s) or business unit) such expenses are to he incurred. An action plan 
also provides a mechanism to establish employee goals and ohjt te and to 

virion action plan may or may not have an impact on the budgeting 
process. A non-impacting action plan, for example, may correspond to a plan/goal that is 
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to be assigned to an employee within the normal scope of the employee's duties and wi th 

which so additional expenses are associated. 

An action plan may be utilized independently or in conjunction with one or more 

profile and KRAs, For example, a user (e.g., a budgeting manager or department head) 
5 may evaluate defined profiles mid KRAs via their appropriate GUIs (see, e.g., Figs. 19 A 

and 21) and formulate as action pian(s) for some or all of die KRAs and profiles within 

the user's responsibility. One or more action plans may be developed to achieve revenue 

targets associated with each ERA or profile and to identify expense items in the CQA 

(hat may be affected by such action plans, 
hi Table IX illustrates an example of die types of fields that, may be defined to create 

an action plan in accordance with an aspect of tlie present invention. The fields and their 

relationship within the system 150 (Fig. 4) may be better appreciated with reference to 

Fig. 22. 
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TABLE IX 



Field Name 


Description/Functionality 


Action Plan Name 


The name of the Action Plan 


Name 


The KRA name that ma> be ; h ith the 
Action Plan 




The description of the particular Action Plan 


Pi >U 


The starting attribute (COA) for the Action Plan 




'Hie ending account (COA) for the Action Plan 


Accumulator 


The user can ei ther select Account From and 
Account To or an Accumulator that has bee?) 
defined in the system 




The date range for the Action Plan 


SiC ! fo 


The Job Description (e.g., employee) to which the 
Action Plan is assigned to 


Ik < > j 


The due date for the particular Action Plan 


Status 


Indicates whether the action plan is active or 
inactive 


i ' foment 


Comment describing the current status of the 
Action Plan 


Completion Date 


The Completion Date for the particular action plan, 
which is set when the Action Plan was created. 




The type of impact - percentage or Absolute Value 


Method 


In case of a percentage type of impact, a user may 
select a roetho* t< tpph i < % tl $ impact 


Impact % 


The value of impact in percentage terms 


Impact Value 


The absolute value of the impact 



Fig. 22 illustrates an example of an action plan GUI 690 that may be utilized to 
add, remove, and/or manipulate action plan data in accordance with an aspect of the 
present invention. The GUI 690 includes a user interface element 692 that may have a 
down menu that is utilized to enter or select a name of an action plan. Another user 
interface element 694 may he employed to link the selected action plan to a selected KRA. 
from a plurality of predefined KRAs. A user also may enter a description of the action 
- . >* 

As mentioned above, an action plan may he applicable to one or more accounts of 
y V over a selected date range. In this regard, the act c I 690 also 

includes user interface elements 698 and 700 for entering a range of one or more 
uts, arai a drop-down menu element 702 for alternatively entering a selected 
■■ ■ v amis. Additional user-interface elements 704 are prt ecting an 
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(IS 1 v its range for an action plan (eg., a range over which the expense may be 
> i due dais by which the action plan is to be completed. 
The action plan GUI 690 also includes a user interface element 706 for entering a 
! : i£ v whom the action plan is assigned. Additional fields 708 and 710 

5 may be provided to enter a stains value for the action plan (e.g\, active or inactive) and 
comments thai may pertain to the action plan. An action plan further may be linked with 
one or more external applications 80, 32, and/or 84 (Fig. 2), such as through the fields 
entered at elements 706, 708, 710 through which an employee may receive information 
identifying his/her goals and objectives. 

20 The GUI 690 further includes an impact interface feature 712, with which a user 

may select the type of impact (percentage or absolute value) as well as a numerical value 
for the impact according to the selected type of impact. The impact interface feature 712 
. further may include a method selection user interface element 7 1 4 for linking a method to 
the identified action plan in accordance with an aspect of the present invention, such as 

.15 when a percentage impact type is selected. As described above, an action plan may he 
linked to a predefined method that is to be applied to the selected account^), such as to 
correlate related data and provide an indication as to the action plan's impact on one or 
more accounts. The method selection user interface element 714 may include a drop 
down menu listing the available methods that are applicable based, on how the accounts 

20 have been selected (via user interface elements 698, 700, 702). For example, some 
methods may only be applicable to a single account, other methods may be applicable to 
range of accounts, and other methods may be applicable to a set of accounts, such as may 
he defined by an accumulator. 

By way of example, if a percentage impact is entered for a particular action plan 

25 attribute (e.g., an account of the COA), an associated method may provide an impact 
value lor each account associated with the action plan. By way of example, an action 
plan designed to achieve a desired result (e.g., an action plan to increase the number of 
contract moms sold at a hotel) may have a cost impact associated with achieving that 
goal For example, additional advertising money may be required to solicit business from 

30 corporate clients. The action plan may further include an associated method (e.g., an 
advertising expense method), which is applied to fee historical data to determine some 
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vultje indicative of the impact on the identified accounts. The method processes the 
historical data to determine a number based on the operands and expressions in the 
assigned method. The impact percentage is applied to the method number (e.g., an 
amount by which fee identified accounts may be impacted as a result of an increase or 
5 decrease in advertising dollars for fee action plan), which corresponds to fee impact value 
associated with the corresponding action plan. Moreover, a user may modify a defined 
action plan value (the impact value, the method, etc.), sneh as via the GUI 690, which, in 
torn, may result, in a corresponding update in the impact value associated the related 
accounts, 

10 The GUI 690 also includes action buttons 716 that may be activated or selected to 

add a new action plan, edit an existing action plan, delete an existing action plan, save a 
action plan to the system database, cancel a previous operation, and/or to son through 
stored action plans. The GUI 690 also may include action buttons 718 and 720 that 
provide links to a profile manager and lo a KRA manager, respectively. The buttons 718 

15 and 720 may be employed to facilitate coordination between an action plan and one or 
more profiles and/or KRAs. For example, (he profile action burton 71 8 may display a list 
of profiles to which the current action plan belongs. Similarly, tbe KRA action button 
720 may allow a user to view fee KRA to which the action plan belongs. 

Fig. 23 is an example of a GUI 730 containing tables 732 and 734 that list the 

20 names for each KRA and action plan, respectively. The KRA table 732 includes fields 
736 and 738 .for the KRA name and a profile type, with winch each KRA may be 
associated. The KRA table 732 is also associated with action buttons 740 that may be 
activated or selected to add a new action plan, edit an existing action plan, delete an 
existing action plan, save a action plan to the system database, and/or cancel a previous 

25 operation. Similarly, the action plan table 734 includes fields includes fields 742 and 744 
for identifying the action plan name and a profile type, with which each action plan may 
be associated. Action buttons 746 also are associated with the action plan table 734. 

WQEKJBENCH 

30 Fig. 24 is a functional block representation of the work bench component 174 in 

accordance with an aspect of fee present invention. Briefly stated, work bench provides a 
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i 5 letionality associated with otl e< f. 
150 to as 1 ic s etiag, forecasting, irertd analysis, aad'or business planning 

downt - svel at which data is stored for any aspect of a company or business. 

The work, bench component 174 includes a work bench manager 760 that 
5 coordinates budgeting and forecasting processes with various components that comprise 
the system 150 (Fig, 4). A user interface 762 is associated with the work bench manager 
760 through which the user may eater and/or select budgeting/forecasting parameters 764 
that are to be applied to data (e.g., historical and/or computed data) stored within the 
system. The parameters 764, may, for example, correspond to an account range, a 

H> selected user-defined calendar, a date range within one of fee calendars, or any other 
parameters that may be utilized to help define and/or formulate a budget/forecast. 

For example, the work bench manager 760 is associated with the method manager 
402, a calendar manager 766 (which may include the calendar alignment function 548 
and calendar attribute function 566), the profile manager 610, as well as managers 768 

15 and 770 that are respectively associated with the KRA component and the action plan 
component. The work bench manager further may include a work bench view component 
through which a user may selectively view and compare current budget/forecast data with 
lata for one or more previous years. As a result, a user may better 
determine the efficacy of budgeting/forecasting parameters and, if desired, selectively 

20 modify various aspects of the budget for one or more accounts of the COA. Moreover, 
the work bench view in conjunction with the various interrelated interface components 
402, 766, 768, 770, 610 facilitates implementation of speculative scenarios, in which a 
user may see how various aspects of the budget may be affected if certain changes are 
made to one or more methods, KRAs, Calendar attributes, action plans, profiles, etc. 

25 implement such scenarios through the work bench component may he referred to as a 
"What if..." analysis. The user mterface 762 thus provides a powerful centralized tool 
through which a user may utilize the other components that form the system 150 (Fig. 4) 
to produce an effective budget/forecast so as to increase profits. 

A report manager 774 also may be associated with the work bench manager. The 

30 report manager 774 provides a tool from which a user- may create budget reports based on 
user-defined parameters. 
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Table X illustrates examples of data fields that may be entered to implement 
bi each COA ID in a given budget in accordance witis as 
aspect of the present invention. The Table X may be better appreciated with reference to 
Fig. 25A, 

TABLE X 



Field Name 


DescripttoH/I^octiofiality 




\ j ix e i for U \ i * jf 


m\ type 


A drop down menu for selecting an account 
type 


Source 


I t ! „ ,ii i ■ .If r j 


1 oa yAJnst 


A drop down menu for selecting a type of 
currency or a unit 


Account From 


A starting account for a budget process 


Aocoum To 


An ending account tor a budget process 


From date 


rling date foi the budget pi< <> < 


To Date 


An ending date for the budget process 


Budget orientation 


The mode of orientation for the budget process 


Load 


Initiates loading of a current budget 




A field tor displaving an account ID (COA ID) 


Rat?' ceilings 


',, ] 'li, i t 


Reference Method 


< ' t it ! ,v.R! ' ' ! 

,» iod.nh co for budgeting 


Method 


A user selectable field indi ating ba method 
i _d k-r 


Bass data 


A field indie; in fa utget data based on 
. t ! s d to stored data 


Impact 


A. field gives the net impact in numbers 
(according to the currency/unit) 


Mamus s < 


A user selectable field for specifying an impact 
in numbers (according to the currency/unit) 


Budget. 


The sum of the budget data and impact 


Ref2 


A field indicating budget data based on foe 
Reference Method 


Variance 


I variance based on I cf u uh<\ 



Fig. 25 A is as example of a work bench manager GUI 800 (illustrated as naming 
on an In ternet bro wser) in accordance with an aspect, of the present invention. The GUI 
i t . 1 define the budget/forecast characteristics that are to 

be displayed hi connection with an identified budget/forecast process. The GUI 800 
includes a user interface element 802 for specifying which budget/forecast process is to 
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be active, such as may be selected from an associated drop down menu. The GO! 800 
also inch, : j . siemeats 804 and 806 for respeel ; t a type of 

account (e.g., expense, revenue) and the units (e.g., U.S. dollars, rooms, number of 
covers, etc.) that are to be utilized for the specified accounts. Account user iuter&ee 
5 elements 808, 810, and 812 also are provided for entering which accounts are to 
employed by the work bench component, which accounts may he selected by specifying 
an account range or by selecting a desired accumulator name. A date range for 
analysis also may be selected via user date interface features 814 and 81.6. 
The GUI further includes an orientation interface element 818, by which a user may 

so select a desired orientation, such as a uniform application, by day of the week, periodic, 
weekday, or weekend, Certain orientations may be limited according to other parameters 
selected, such as according to the account type at 804 and/or units at 806. 
Ones the foregoing parameters have been programmed a user may load corresponding 
budget data into active memory, such as by activating a "load" action burton 820. As a 

IS result oi act i ad button 820, corresponding budget/forecast data is displayed 
on an interactive display portion 822 of the GUI 800. The display portion 822 is 
interactive because it allows a user to select certain displayed fields associated wife m 
account and to modify its associate attributes. As indicated with respect to table X, die 
display ed fields include an indication whether die data has been budgeted before 824, for 

20 example, if the account item has been budgeted before a check mark may show in an 

associated box with that account ID. An account Id field (COA ID) 826 also is displayed 
for fee budget/forecast data. The account ID indicates which account in the COA fee data 
represents. 

The remaining fields 828 through 840 are user selectable fields thai may be 
25 adjusted to alter fee associated budget data, A reference method field 828 indicates fee 
reference method assigned to that account ID for the present units being employed. A 
user, for example, may select a reference method field associated with a particular 
account ID to modify the reference method. Tire result of the reference method may be 
- • i field (not shown) that may be compared with the computed 
30 * l nt in the selected range. Similarly, a reference ceiling may 

be changed to provide for other reference ceilings. The display 823 also includes a 
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method field entities the base method (st^ e.g., Fig. 1 Id) that is assigned to 

each account. The user may activate fee field in order to select an alternative method to 
be applied from those methods associated witfi that account. The base data field 834 
indicates a base level of budget/forecast data for an account based on applic ation of the 
method of field 832 to the stored data. Accordingly, if the method in field 832 is 
modified, the budget data in field 834 also might change. 

The display portion 832 further includes an impact, field 836 that displays the 
impact associated with that account. As mentioned above, the impact may be an 

i . o a aafity of impact values based on, for example, KRAs, action plans, 
and/or calendar attributes associated with the displayed account. A user may activate the 
field 836 to selectively modify one or more of such criteria. For example, a user may 
modify an associated KRA, action plan or calendar attributes to result in a modified level 
of impact on that account. In addition, a user may enter manual changes at field 838. 
The manual changes entered by a user may result in a system generated OA having an 
1 it field 830. Each time such changes are made, the 

corresponding budget data also is modified so that the user may see on the display 82.2 
how such changes affect the budget/forecast data. The results of the budget data are 
provided in field 840, which combine the base data at field 834, the impact data at 836 
and the manual changes entered at 838. A value associated with the reference method at 
field 828 also may be displayed as well as a variance in field 842. 

Another powerful tool associated with the work bench component is a 
budget/forecast view feature. The view feature includes a GUI 850 for displaying a 
comparison of fee current, budget/forecast. The GUI 850 includes a source selection 
interface 852 in. which a user may identify the source of the data being displayed in the 
btldget/toreeasl work bench view GUI 850. The displayed data may include the account 
ID together wife the description thereof, indicated at 854. Next to each account number, 
are the data for the current budget (field 856} and the data associated with thai account 
from one or more previous years (fields 858). 

In die example of Fig. 25B, a view comparison is displayed for Budget 2000 Rev. 
1, m a side -by-side comparison with the corresponding budgefc'Torecast for each selected 
account for one or more previous yeans (eg., a three year comparison). Accordingly, the 
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data associated wi& each account Identified, is the budget parameters is displayed next to 
budget data f p vious years. Accordingly, a user may compare as intermediate 
budget that a user is preparing with the previous budget/forecast data to determine 
whether the numbers so far appear in line with the historical numbers from fee three 
5 previous years. If the user is not satisfied with the results the user simply may switch 

hack to the work bench manager QUI 800 that is shown In Fig. 25a and make changes to 
one or more budget parameters to adjust the budget data accordingly. This process may 
be repeated to perform the "what if 9 analysis described above. Once the budget is 
satisfactory to the user, the user may select a finish action button 860 in the GUI 800. 

W Figure 25e illustrates an example of a GUI 862 that may be employed to set up 

and identify a budget for a desired year. The GUI 862 includes fields 864 for entering a 
budget name and a description thereof. Another user interface element 866 is provided 
for entering a year for the budget/forecast identified at 864. In addition, a user may- 
specify a date range for which die budget is to be computed at 868 . All data associated 

ts w hen be stored in system memory. 

After the budget/forecast data has been finalized, a user may activate a 
synchronisation .process for a selected budget/forecast ID covering an account type and a 
selected currency unit. A user also may specify an account range and a date range for 
which budget/forecast data is to be s}mehronized. 

20 In view of the foregoing, the work bench component I 74 provides a centralized 

interface that provides a powerful tool with which a user may view selected aspects of the 
budget, Moreover, a user may selectively modify KRAs, action plans, calendars, 
calendar attributes, methods, and/or profiles and be provided an visual indication via the 
user internee as to how each such change may affect the current budget and/or forecast. 

25 As mentioned above, modification of a single parameter may have a resounding impact 
on numerous aspects of a budget The work manager 760, in conjunction with the other 
component managers, simplifies the entry of such changes into a budget and may provide 
a nearly instantaneous result for such changes on an entire budge. Fmthermore, multiple 
budgets (or aspects thereof) may be displayed to a user via the user interface 762 for a 

30 side-hy-side comparison. As a result, a user may easily fine tone budget characteristics 
so as to maximize profits. 
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In order to provide additional context for various aspects of fee present invention. 
Fig, 26 and the following discussion ate intended to provide a brief, general description 
of a suitable computing esnvircoanent 900 in which the various aspects of die present 
invention .may be implemented. While the invention has been described above in fee 
general context of computer-executable instructions that may ran on one or more 
computers, those skilled in the art will recognise that the invention also may he 
implemented in combination with other program modules and/or as a combination of 
hardware and software, Generally, program modules include rotdines. programs, 
components, data structures, etc. that perform particular tasks or implement particular 
abstract data types. Moreover, those skilled in the art will appreciate that the inventive 
! I say b • need with other computer system configurations, including single- 
r v , omputer systems, minicomputers, mainframe computers, as 
well as personal computers, hand-held computing devices, microprocessor-based or 
programmable consumer electronics, and the like, each of which may be operatively 
coupled to one or more associated- devices. The illustrated aspects of the invention may 
also foe practiced in distributed computing environments where certain tasks are 
performed by remote processing devices that are linked through a communications 
network. In a distributed computing environment, program modules may be located in 
both, ted and remote memory storage devices. 

With reference to Fig. 26. an exemplary environment 900 for implementing 
various aspects of the invention includes a server computer 902, moulding a processing 
unit 904, a system memory 906, and a system bus 908 Chat couples various system 
components including the system memory to the processing unit 904. The processing 
unit 904 may be any of various commercially available processors, including but not 
! <S6, .Pentium and compatible microprocessors from Intel and others, 
including Cyrix, AMD and Nexgen; Alpha from Digital; MIPS from MIPS Technology, 
NEC, IDT, Siemens, and others; and the PowerPC from IBM and Motorola. Dual 
micjoprocessors and other multi-processor architectures also can be used as the 
processing unit 904, 
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The system bus 908 may be any of several types of bus structure including a 
memory bus or memory ca u 1 a peripheral 1 < > ny of a variety 

of conventional bus architectures such as PCI, YES A, MicroChannel, ISA, and EISA, to 
name a few. The server computer 902 memory includes read only memory (ROM) 910 
and random access memory (RAM) 912. A basic input/output system (BIOS), containing 
the basic routines thai help to transfer information between elements within the server 
computer 902, such as during start-up, is stored in ROM 910. 

The server computer 902 farther includes a hard disk drive 914, a magnetic disk 
drive 916, e.g., to read from or write to a removable disk 91 S, and an optical disk drive- 
920, <?,#., for reading a CD-ROM disk 922 or to read from or write to other optical media. 
The hard disk drive 914, magnetic disk drive- 916, and optical disk drive 920 are 
connected to the system bus 908 by a hard disk drive interface 924 >, - . « • ! 

. '-Jhce 926, and an optical drive interface 92S, respectively. The drives and their 
. . u • mputer-readable media provide nonvolatile storage of data da ' « > 
computer-executable instructions, etc. for the server computer 902, including .for the 

of broadcast programming in a suitable digital format. Although foe description 
of computer-readable media above refers to a hard disk, a removable magnetic disk and a 
CD, it -should he appreciated by those skilled in the art that other types of media which 
are- readable by a computer, such as magnetic cassettes, flash memory cards, digital video 
disks, Bernoulli cartridges, and the like, may also be used in the exemplary operating 
enyiro.mne.nt, and further that any such media may contain computer-executable 
instructions for performing foe methods of the present invention. 

A number of program modules may be stored in foe drives and RAM 91.2, 
udia;i .i?. jperaihtg system 930, one or more application programs 932, other program 
modules 934, and program data .936. The operating system 930 in the illustrated 
computer is, for example, foe "Microsoft Windows NT" operating system, although it is 
to be appreciated that the present invention may be implemented with other operating 
systems or combinations of operating systems, such as UNIX, XJNTJX, etc. 

A user may enter commands and information into the server computer 902 
through a keyboard 938 and a pointing device, such as a mouse 940. Other input devices 
shows iay ii hide a microphone, an IR remote control, a joystick, a game pad, a 
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satellite dish, a scanner, or the like. These and other input devices are often connected to 
the processing unit 904 through, a serial port interface 942 thai is coupled to the system 
bus 908, but may be connected by other interfaces, such as a parallel port, a game port, a 
universal serial bus ("USB"), an IR. interface, etc. A monitor 944 or other type of display 
device is also connected to the system bns 908 via an interface, such as a video adapter 
946. In addition to the monitor, a computer typically includes other peripheral output 
devices (not shown), such as speakers, printers etc. 

The server computer 902 may operate in a networked environment using logical 
connections to one or more remote computers 948. The remote computer 948 may be a 
workstation, a server computer, a router, a personal computer, microprocessor based 
appliance (e.g., a palm computer), a peer device or other common network node, and 
typically includes many or ail of the elements described relative to the server computer 
902, although, for purposes of brevity, only a memory storage device 950 is illustrated in 
Fig. 26. The logical connections depicted in Fig. 26 include a local area network (LAN) 
952 and a wide area network (WAN) 954. Such networking environments are 
commonplace in offices, enterprise-wide computer networks, intranets and fee Internet 

When used in a LAN networking environment, fee server computer 902 is 
connected to die local network 952 through a network interface or adapter 956'. When 
used in a WAN networking environment, the server computer 902 typically includes a 
modem. 958, or is connected to a communications server on the LAN, or has other means 
; communications over the WAN 954, such as the Internet. The modem 
958, which may be internal or external, is connected to the system bus 908 via the serial 
pott interface 942. In a networked environment, program modules depicted relative to 
the server computer 902, or portions thereof, may be stored in the remote memory storage 
device 950. It will be appreciated that tire network connections shown are exemplary and 
other means of establishing a communications link between the computers may be used. 

hi accordance with the practices of persons skilled in the art of computer 
programming, the present invention has been described with, reference to acts and 
symbolic representations of operations that are performed by a computer, such as the 
server computer 902 or remote computers) 948, unless otherwise Indicated. Such acts 
and operations are sometimes referred to as being computer-executed. It will be 



50 



WO 02/13102 



PCT/IJS01/24661 



appreciated that the acts and symbolically represented operations include the 
manipulation by the processing unit 604 of electrical signals representing data hits which 
causes a resuming transformation or reduction of the electrical si| « i 5 and 

the maintenance of data bits at memory locations m the memory system (jncludmg the 

5 system memory 906, hard drive 914, floppy disks 918, CD-ROM 922} to thereby 
reconfigure or otherwise after the computer system's operation, as well as other 
processing of signals. The memory locations where such data bits are maintained are 
physical locations that have particular electrical, magnetic, or optical properties 
corresponding to fee data bits. 

to In view of trie foregoing structural and functional features described above, 

methodologies in accordance with various aspects of the present invention will be better 
appreciated with reference to Figs. 27-35. While, for purposes of simplicity of 
explanation, the methodologies of Figs. 27-35 are shown and described as a series of 
steps, it is to be understood and appreciated that the present invention, is not limited by 

15 the order of steps, as some steps may, in accordance with the present invention, occur in 
different orders and/of concurrently with other steps from thai shown and described 
herein. Moreover, not all illustrated steps may be required to implement a methodology 
in accordance with an aspect the present invention. 

Fig. 27 is a flow diagram illustrating a methodology to facilitate budgeting, 

20 forecasting, business planning and/or analysis in accordance with an aspect of the present 
invention. As set forth above, a methodology, in accordance wife the present invention, 
may be implemented as computer executable instructions embodied in a computer 
readable medium that may run on a computer, such as a server or another computer. The 
process begins at step 1000 in which parameters associated with the methodology are 

25 initialized and appropriate flag conditions are set to their starting values. The process 

proceeds to step 1002 in which a chart of accounts is created. As mentioned above, a 
chart of accounts is a list, such as may be stored in a table, that defines account entries 
associated with a particular aspect or operating characteristic of a facility or a group of 
facilities or business units. 

30 Next, at step 1004, a database is generated. The database may include records 

collected from a plurality of data sources and translated into a desired consistent record 
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format, such as described above with respect to Fig. 1 . The database includes records in a 
consistent format, such as the OKBAA format described herein, which may be include 
both collect* 1 I uted data, The process then proceeds to step 1006. 

At step 1 006, one or more calendars are set up. A budgeting calendar may be any 
duration, such as a single day, a month, a fiscal quarter, a year, or any other time period 
for which data may have been acquired or which may otherwise be pertinent to 
budgeting/forecasting* Additionally, the calendar may include a period of one or more 
identified days that may include events, holidays, convention dates, renovations, etc. 
Each identified day may have one or more designated account attributes associated wife 
the days that may affect a budgeting or forecasting process. 

Next, the process proceeds to step 1008 in which one or more methods are 
created. As mentioned above, such methods may be predefined ami/or a user may create 
methods that establish rales or formulas feat define how data is to be retrieved and how 
an impact or other useful information may be extracted from the retrieved data. From 
step 3008 the process proceeds to step 1010 in which one or more profiles are created. A 
profile may be created by a user to model circumstances or situations that may affect on 
operations at a facility or an operating unit thereof. By way of example, profiles may 
model competition in an area, certain attractions local to an area, the weather in the local 
area, a foreign economy that may affect local tourism and, in turn, one or more aspects of 
a facility, etc. Each profile provides a qualitative and/or quantitative analysis of the 
ohxjnmstatices that are profiled, from which a user may, in turn, generate one or more 
KIlAs to achieve a desired result with respect to each profile andV'or one or mote action 
plans that provide a qualitative and/or quantitative indication of the impact associated 
with achieving a desired result. 

From step .1010, the process proceeds to step 1012 in which one or more KRAs 
axe created. As mentioned above., a KRA may be independent or it may be associated 
with a profile and/or one or more action plans. Each KRA includes data characterising a 
desired result with an impact value associated with an account identified in the KRA data, 
A KRA also may have a method (step 1008) associated with the KRA to derive an impact 
based on application of the method to stored data (collected data and/or computed data). 
From step 3 012 the process proceeds to step 3 014. 
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At step 1014, oae or more action plans are created. As mentioned above, an 
action plan may be independent or it may be tied to one or more profiles and/or KRAs. 
Bachac i impact pa aneter that quantifies the impact (e.g., cost) on 

fe« 1 >udg< i m ; > b coasting process associated with implementing an action plan. 
As mentioned above, however, the impact value may be zero. Moreover, an action plan 
may employ a method (such as created at step 1 008} to determine the impact (e.g., a cost 
- labor, dollars, etc.) associated wife implementing the respective action plan. 

Next, at stq? 1016, budgeting/forecasting parameters are selected to define the 
characteristics for which a user desires to generate a budget and/or forecast Such 
parameters may include a date or date range, a range of accounts in the CO A to which the 
user may desire to limit the budget, as well as other parameters associated with the 

< u r.feess. From step 1016, the process proceeds to step 1018 in 
which a budget/forecast is generated based upon the parameters and data associated with 
steps 1 002 through 1 016. By way of example, a graphical user interface, may display a 
plurality <- v f » n t the budget which a user may view and if desired modify 

1 i to create 

additional revisions in accordance with an aspect of the present invention. Prom step 
101.8 the process proceeds to step 1020, in which a determination is made, suitably by the 
user, as to whether the budget/forecast appears satisfactory . If the budget is satisfactory, 
fee process proceeds to step 1022 in which the associated data is saved, such may be 
identified as a revision of a particular budget/forecast. From step 1 022, fee process ends. 
If fee determmation at step 1020 is negative, indicating that the budget is not satisfactory,, 
fee process proceeds to step 1024. 

At step 1024, a user may revise selected parameters, such as by employing a user 
interface associated wife an appropriate tool (eg., the work bench). By way of example, 
the user may redefine one or more calendars associated with the budget, such as by 
entering or modifying calendar attributes (special days and accounts associated 
' ' ^ ' ; i iuionsdly or alternatively, a user may create additional profiles and, in 
fern, create additional KRAs and/or action plans associated with the new profiles. The 
user also may create or modify KRAs or action plans independently of profiles. A user 
also may enter manual changes for a selected account, in response to which a system- 
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g£. iterated K I When a user modifies an aspect of the budget an auto- 

generak fe > ol ite new budget/forecast data. The process 

eventually returns to step 1022 in which the user determines whether the budget is 
ehud lis isfaetory the process may end. 
As a result, the methodology of Fig. 27 provides a powerful budgeting and/or 
jsting tool that enables the user to derive budgets or forecasts for a facility, a group 
of facilities or business anils within one or more facility that ate capable of reflecting the 
impact of the internal operating data within the facilities or business units in conjunction 
with the impacts associated with external factors. Moreover, fee methodology enables a 
user to achieve desired results and implement actual action plaits and to monitor their 
p set on the budget and/or forecast. The process may be implemented with respect to 
any level of time period (eg., from a day to a year) and wife respect to any range of 
accounts (e,g,„ irons a single account to alt accounts) for a company or a business unit 
thereof. 

Turning now to Fig. 28, a methodology for creating an OKRAA database and an 
OLAP database in accordance with one aspect of the present invention is flow charted. 
At step 1.100, the point of sate applications, databases, file systems and data soutces are 
identified. This identification can include, but is not limited to, names of the data 
sources, types of data in the data sources, record formats of the data sources, the account 
identifiers associated with the data sources, physical locations of the data sources and the 
computer systems supporting the data sources. Next, at step 1 102, non-point of sale 
applications, databases, file systems and daiasources are identified. This identification 
can include, but is not limited to, names of the data sources, types of data in the data 
sources, record formats of the data sources, the account identifiers associated with the 
data sources, physical locations of fee data sources and the computer systems supporting 
t ? Next, ai step 1104, the external applications, databases, file systems and 
data sources are identified, litis identification can include, but is not limited to, names of 
fee data sources, types of data in fee data sources, record formats of the data sources, the 
account idenii fie; ci ited with the data sources, physical locations of the data sources 

ems suj 5 he data sources. White, for purposes of 
illustration, point of sale, non point of sale and external data sources are flow charted in 
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Fig. 28, it will be understood and appreciated by those skilled in the art that other types of 
data sources that collect or store data that may affect a facility or any business or industry 
may be utilized in accordance with the present invention. 

From step 1 104, the process proceeds to step 1106, in which FMS SQL databases 
are generated, Further detail concerning step 1106 is included in Fig. 29. Next, at step 
1 108, fee FMS SQL databases are used to populate a central storage. Next, at step 1 1 10, 
the central si [ueried and processed on a scheduled and/or ad hoc basis to create 

an OKRAA database in accordance with the present invention. Next, at step 1 1 1 2, the 
OKRAA database is queried and processed to create an OLAP database. 

Turning now to Fig. 29, a methodology for generating FMS SQL databases in 
- u v» n one aspect of the present invention is flow charted For each record 
pushed or pulled front a data source, steps 1200 through 1212 will be performed. At step 
1200 the raw data is collected from the data source. At step 1202 the source and account 
identifier associated with a raw data source is identified. '.Then at stop 1204 the account 
> lookup << i ! stored in an FMS rule set. After the 

< tc i\ ■> ^e lonnd, die pu : step 1206 in which the rules are 

applied to fee raw data to create translated date. Then at step 1208 additional fields 
necessary to create die desired FMS record format are created. After the data has been 
translated and the additional necessary fields have been created, dre process proceeds to 
step 1210. At step 1210, an FMS format record corresponding to the collected raw data is 
created. Then, at step 1212, the FMS record is stored in the FMS SQL database. 

Fig. 30 illustrates a methodology for processing FMS SQL databases to create a 
central stora ; t 'tee with one aspect of the present invention. For each record 
pushed or pulled from an SQL database, steps 1300 through 1312 will be performed. At 
step 1300, the FMS SQL database from which the record originated is identified. At step 
1302, an FMS record, including its account, identifier is retrieved. As mentioned above 
an account identifier can be used as a primary key to access records from one or more 
tables thus facilitating translation and other processing. Next, at step 1304 the account 
identifier is used as a key into the OKRAA rule set to lookup the translation rules to 
determine which rule or rales apply to this record. After die translation rales are round, 
the process proceeds to step 1 300, in which toe rules are applied to the FMS record of 
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step 1302. Alter the data translations have occurred at step 1306, any additional fields 
required, as noted h fee rule set, are created at step 1308. For example additional fields 
may be required to identify the source of the data, and to record creation and update 
information. 

from step 1308 the process proceeds to step 1310 where an OKRAA format 
record is produced, As noted above* an OKRAA format record may include a 

s > f base fields and variable fields. The base fields may contain information 
associated with, for example, identifying a data source, identifying a transaction amount, 
identifying a currency type and identifying a date. The OKRAA record format k 
extensible to Include account fields containing information associated with, for example, 
identifying a she, identifying a department, identifying an account, identifying a sub 
account and identifying a minor account. Next, at step 1312, the OKRAA format record 
is written to the central storage database. 

Figs. 31 and 32 are flow diagrams that illustrate a methodology for setting various 
aspects of a calendar component in accordance with an aspect of the present invention. 

^ it step 1400, in which a user enters desired calendar set up 
parameters, The set tip parameters may, for example, include the names, types of 

d < t > rods of user-defined calendars for a budget/forecast period, 

such as a selected year. From step 1400, the process proceeds to step 1402, in which a 
first day of the bndget'foreoast yeas- is aligned with a like day in each historical year. For 
example, if a start day of a particular budget/forecast year is the second Tuesday of the 
year, the corresponding 365 days of each historical calendar year would utilize the second 
Tuesday of that year as its starting day for the corresponding calendar-. In tins way, the 
calendars are aligned by day of the week, and not the date, so as to improve upon the 
relevance of the historical data, This improves the reliability and accuracy of the 
budgeting and/or forecasting process for the various industries, such as the hospitality 
industry. As mentioned above, the day of the week has a significant impact in the 
budgeting characteristics in certain types of industries. 

Next, at step 1404, a user-entry and mapping process is performed, in which each 
special da> : si nat < with the calendar set up data (step 1400} is mapped to 

espos data The mapping p >< s is describe • ith respect to 
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"~ ■ > , $4 the process proceeds to step 1406 in wMc.h the consistent 
calendar data is stored. Pros 06 the ealend et up x Wi 

mapping and jndara mem processes are illustrated together in Fig, 31, it is to be 

I appreciated < -« processes are indepea ic i other and, 

thus, could be implemented separately, 

*g» io F 12 the process of mapping special days to the historical data 
(step 1404) is illustrated. From step 1404, the process proceeds to step 1410 m which the 
days o f interest are entered, such as through a suitable user interface element {e.g., Fig. 
17). Next, attributes for each special day are designated. Hie designation may be 
predefined according to the type of the special day. For example, holidays (or selected 
holidays} may have a particular impact on certain accounts at a facility. The effect of 
such speei < s ■< been recognized over time or based on an event estimation, 

such as may be provided by an event coordinator. One or more accounts may be 
designated to deri ve a corresponding impact value for each respective, designated account 
From step 1412, the process proceeds to step 1414. 

i 1 i i ! !>i i i i t x ki> been 

located in the historical data. By way of example, the most recent historical year may be 
searched (e.g., by name, description and/or other characteristics) first to determine 

ether the spe» \x Subsequently, if no matches are found, 

each proceeding year may he then searched. If the special day is not located in the 
historical data, the process proceeds to step 141 6 in which a zero impact is assigned for 
the designated attributes for mat special day. Additionally, the historical data associated 
wife the same site may be searched first. If the event is not located with respect to the 
same site, data associated with other sites may be searched to locate the identified special 
day, as the impact for a particular event at one site may have a substantially similar 
impact at a different site. From step 1416, tire process proceeds to step 1418. 

At step .1 41 g, a determination is made as to whether there are any additional 
special days having designated attributes for which an impact value may he determined. 
For example, if a user wishes to enter additional days, the process proceeds to step 1412 
in v> inch tK i> s ate designated. If there are no additional days having such 
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designated attributes, the process proceeds to step 1420 in which the process returns to 
step 1406 of Fig. 31. 

k the de ttinnative, indicating that the special day has 

been located in the histories! data, the process proceeds to step 1424. At step 1424, the 
special cay is located in a proceeding calendar year of the historical data. By way of 
example, if the special day is an annual event, such as an annual holiday, it may be 
desired to locate the two most recent adjacent years in the historical data in which the 
special day occurred. Once the special day has been located in two years of the historical 
data, the process proceeds to step 1426 in which the designated attributes for each of the 
years of historical data are compared. Next, at step 1428, an impact for each designated 
attribute is then determined based on the comparison. The impact may -correspond to the 
change or difference in the attributes due to the circumstances associated with the special 
day. From step 1428 the process proceeds to step 1418. It Is to he understood and 
appreciated thai die account data associated with a single day in the historical data also 
could be employed to derive a corresponding impact value in accordance with an aspect 
of the present invention. 

log. 33 is a f;ow diagram illustrating the methodology for generating a Key 
Results Area (KRA) in accordance with air aspect of the present invention. The 
method* 1, iplemented in connection with a user interface running on a 

computer, such as may be operatively coupled to the server through a network 

tractate 1 he process begins at 1 500 in which a name of the KRA is entered. 'Next, 
at step 1 S02 a determination is made as to whether a profile is to be selected for the KRA. 
If a profile is to be selected, the process proceeds to step 1 504 in which the profile is 
entered, such as by selecting from one of a plurality of predefined profiles. From either 
of steps 1502 or 1504, the process proceeds to step 1506 in which selected COA data is 
entered. By way of example, the COA data may include a COA JD that identifies an 
account of a CO A or a range or set of accounts to which fee KRA entered at step 1500 is 
to be applicable, From step 1506, the process proceeds to step 1508. 

At step 1508 a date range is selected for which the KRA is to be applied. The 

d with the KRA thus may he applied over * c< - period in 
the budget/forecast process. For example, the date range may be a single day up to any 
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time pent ( b; achieved. Next at step 1510, the 

selected date range is correlate* < thecal wiar data stored in the database, in this 
way, the- KRA will be applied to each day In the calendar that corresponds to a day in the 
selected date range. From step 1510 the process proceeds to step 15 12, 

At step 1512, a determination is made as.to whether ft k s j 
absolute value impact or a percentage impact type. As mentioned above, an absolute 
value impact type corresponds to a value of impact having units indicative of the 
characteristic of the attribute or attributes for which a result is desired. If a percentage 
impact type is selected, the process proceeds to step 1514 in winch a user may select a 
method to be applied in conjunction wife the KRA being created. Prom either step 1512 
or 1 514 the process proceeds to step 1516. it is to be understood and appreciated by 
those skilled .in the art that a method also could be applied to other types of impact in 
accordance wife an aspect of fee present invention. 

At step 1516 an impact value is entered. 'The impact, value corresponds to the 
impact type selected at step 1512. For example, if an absolu te value impact type is 
selected, the impact value will have units of a type feat correspond to the attri bute for 
which a result is desired. For a rooms sold attribute, for example, an absolute value 
set type will have a number characterizing a desired increase or decrease in fee 
number of rooms sold, whereas a percentage impact type would be a percent increase or 
decrease in fee rooms sold. From step 1516, the process proceeds to step 1518 in which 
the KRA data is saved. 

Fig. 34 is a .flow diagram illustrating fee methodology for generating an. action 
plan in accordance with an aspect of fee present invention. The process begins at 1600 in 
which a name of the action plan is entered. Next, at step 1602 a detenmnation is made as 
to whether a KRA is to be selected for the action plan. If a KRA is to be selected, fee 
process proceeds to step 1604 in which fee KRA name is entered, such as by selecting 
from one of a plurality of predefined KRAs, From either of steps 1602 or 1604, the 
process proceeds to step 1606 in which selected COA data is entered. By way of 
example the COA data may include a COAJB that identifies an account of a COA or a 
range or set of accounts to which fee action plan entered at step 1600 is to be applicable. 
From step 1606, the process proceeds to step 1608. 
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At step 1 608, a date range is selected over which the action is to be applied. For 
ph 1 late range may be a single day op to any time period during which the 
objective or goal is to be achieved. Next, at step 1610, the selected date range is 
correlated wit i las data stored in the database, In this way, the action plan may 
be applied to each day in a calendar that corresponds to a day in the selected range. From 
step 1610 the process proceeds to step 1612. 

At step 1 612, a determination is made as to whether the impact type is to be art 
absolute value impact or a percentage impact type. If a percentage impact type is 
selected, the process proceeds to step 1614 in which a user may select a method to be 
applied itt conjunction with the action plan being created. It is to be understood and 
appreciated by those skilled in the art that a method also could be applied to other types 
of impact m accordance with an aspect of the present invention. From either step 1612 or 
1 614 the process proceeds to step 1616. 

At step 1616 an impact value is entered. The impact value corresponds to the 
vted at step 1612 For example, if an absolute value impact type is 
tie will have units of a type that corresponds to the account 
affected by implemeutin h jecth of the action plan. For as increased local 

>oie, for example, an absolute value impact type will have a number 
corresponding to a dollars amount of advertising associated with the cost of 
jumkm-.-ouo- *> > ai advertising, whereas a percentage impact type would he a 
percent increase in tire associated advertising budget. 

From step 1616, the process proceeds to step 1618 in which employee data is 
entered. The employee data may include an employee name or business suit to which the 
action plan is assigned. The employee data, for example, may be obtained from an 
associated employee database, such as maybe associated with a payroll processing 
software package or which may be pail of the OKRAA database. The action plan data 
further may indicate the status (active or inactive) of each action plan as well as contain 
information abont the progress of the action plan so that the employee assigned the plan 
(and/or the. employee's supervisors) may monitor its progress. From step 1618, the 
process proceeds to step 1620 in which the action plan is saved. 
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Pig. 35 illustrates a me x oi >g> for implementing a budget work tench process 
in accordance with an aspec > r 1 im tion. The budget work bench may, in 
accord- aspect of the present invention, be implements as computer 

exeeutat c u < ptovide a GUI to facilitate budgeting, forecasting, planning, 

5 trend analysis, or other evaluation of a business or industry. 

The budget process begins at step 1700 by selecting a budget/forecast year for 
which the process is to be applied. Next, at step 1702, an account range is entered for 
which die work bench process is to be applied. The account range may be as small as one 
account, or as many as all accounts in the CQA. Similarly, selected accounts may be 

1 0 grouped by an accumulator. At step 1 704, a date range is entered for which the 
budget/forecast process is to be applicable. 

The process proceeds to step 1706, in which one or more methods are retrieved 
for each identified account for performing the budget analysis. As mentioned above, the 
methods may be selectable, such as by employing a method GUI by which a base method 

I S is associated with a particular account ID for a particular type of currency or unit. A 
reference method also may be associated with each account for computing a reference 
data that may be employed in a comparative analysis for each account. From step 1706, 
the process proceeds to step 1708 in which the methods are applied to the stored data, 
which may include historical and computed data, for each selected account 

20 At step 1710, an impact is calculated based on, for example, one or more KRAs 

associated with each selected account, one or more action plans that may be associated 
with each such account, one or more calendar attributes thai may be associated with such 
accounts, as well as other system generated KRAs. As a result, the impact may be an 
aggregation of a plurality of impact values for each account Next, at step 1712, the 

25 budget/forecast for each selected account is generated based on the -aggregate impact 
value and the based method applied to each respective account. 

Next at step 1714, a determination is made, such as by the user, as to whether to 
modify the budget parameters. The computed budget/forecast data may be displayed 
locally to the user, such as through an appropriate GUI. A user may in tuns view the data 

30 alone or as compared to budget data from one or more previous years, such as associated 
with a work bench view component A user also may endeavor to modify certain 
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budget/forecast constraints to see whether a better more effective budget may be 
determined (e g , the What If the determination at step 1714 is affirmative, 

indicating that the user does not desire to modify the budget/forecast, the process 
proceeds to step 1716. At step 1716, the current budget/forecast may be save. If, 
i »*esr to modify one or more parameters of the budget/forecast 

< te| 1 7 1 S in which such modifications are made. From 
step 171 8, the process may return to step 1706 so that the foregoing process is repeated to 
recalculate the budgei/forecast data based on the modifications. As mentioned above, a 
user may modify one or more KKAs, one or more action plans, and/or one or more 
calendar attributes. A user also may modify methods associated with an account in order 
to derive more accurate and effective budget, data. Once the budget appears satisfactory 
to a user, the user may save to the budget/forecast (step 1716), such as a revision, for that 
budget ID. 

What has beer, described above includes one or more examples of die present 
invention. It is, of course, not possible to describe every conceivable combination of 
tents of met doiog tr<5 purposes of describing the present invention, but ofie of 
ai a I in the art will recognise that many further combinations and permutations 
os the x . i are possible. Accordingly, the present invention is intended to 

jiabraee all such alterations, modifications and variations that fall within die spirit and 
scope of the appended claims. Fmihermore, to the extent that the terms "includes" arid 
variations thereof and "having" and variations thereof are used in either the detailed 
1 ims, such term is intended to be inclusive in a maimer similar to the 

term "comprising." 
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Claims 



What is claimed is: 

1 . A system to facilitate at least one of budgeting and forecasting, 
comprising: 

a database which stores account, data for a plurality of accounts of a chart of 
accounts, the account data being indicative of operating characteristics for fee plurality of 
accounts for a plurality of days over a time period; and 

a method associated with each account of the plurality of accounts for correlating 
selected account data and calculating an expected account value for each respective 
account of the plurality of accounts as a function of the correlated account data. 

2. The syst em of claim 1, wherein a plurality of methods are associated with 
some accounts of the plurality of accounts, at least some of the plurality of methods being 
user-defined methods programmed to correlate selected account data and calculate an 

< oat value to die some accounts. 

3. The system of claim 2 further including a fust user interface through 
which a user selectively defines the user-defined methods. 

4. The system of claim 3 further including a second user interface through 
winch a user selectively applies at least one user-defined method to the account data. 

5. The system of claim 3, wherein each user-defined method includes at least 
one of a logical operator. Boolean operator, operand, and programmatic operator. 

6. The system of claim 1 further including key result area data associated 
with at least one account of the plurality of accounts, the key result area data having a key 
result impact value indicative of a desired result for the at least one account, the expected 
account value for the at least one account being adjusted according to die key result 
impact value. 




7, IT ysiem o claim 6, wherein the key result impact value is a user- 
defined value stored in collection with the at least one account. 

8 - The system of claim fx wherein the key result impact value is determined 
based on application of a method associated with the key result area data to the account 
data. 

9. Tire system of claim 6 further including a profile data structure for storing 
profile data that quanti tatively characterizes factors that affect operation of the at least 
one account, the key result impact value being assigned based on the profile data 

1 0. The system of claim 9, wherein the profile data includes time-based 
account data for at least one profile attribute, the time based accoun t data being 
determined by application of a method to the account date. 

.1 1 . The system of claim 9, wherein the key result area data for the at least one 
account further includes a plurality of key result impact values, at least some of the key 
result impact values being as > 3 on the profile data. 

1 2. The system of claim 6, wherein the key result area date for the at least one 
account includes selectable time data for defining a duration in which fee key result 
impact value is applicable to the at least one account. 

rbe s> stem of claim 12. wherein the duration is divisible into time 
periods, the key result area impact data generating an impact value for each of the time 

14, The system of claim 6., wherein the KJRA impact value further includes a 
computed fCRA impact value determined as a hmction of data indicative of as actual 
impact for a related KRA, the actual impact data be stored in the database. 
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1 5 „ Hie system of claim 6 further including action plan data stored in 
coanecfion with at least another account of the plurality of accounts, the action plan daia 
.having an action plan impact value indicative of a cost associated with achieving an 
objective, the expected account value for the at least another account being adjusted 
according to fee action plan impact value. 

.1 6. The system of claim 15, wherein the objective corresponds to at. least part 
of the desired result of the key result area data and the cost associated with achieving the 
jo! ids to at least part of the cost associated with achieving the desired 

result 

17. The system of claim 16 wherein the action plan further includes a plurality 
of action plan impact values, each action plan impact value indicating a cost associated 
with a respective other one of fee plurality of accounts for achieving the desired result, 
the expected account value for each of the other accounts he adjusted according to a 
respective one of the plurality of action plan impact values. 

18. The system of claim 1 further mcluding action plan data stored in 
connection wills the at least one account, the action plan data having an action plan 
impact value indicative of a cost associated with achieving an objective, fee expected 
account value for the at least one account being adjusted according to the action plan 
impact value. 

1 9. The system of claim 1 8, wherein the action pl an impact value is 
determined based on application of a method associated with the action plan data to the 
account data. 

20. The system of claim 1 8, wherein the action plan data further identifies an 
assignee to which the action plan is assigned. 
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2 1 . The system of claim 20, wherein the action plan data farther includes data 
identifying a due date by which the assignee is to complete the - sedated with 

the action plan, 

item - < iaim 20, wherein the action plan data further includes data 
identifying the status of the action plan data, the action plan impact value being applied in 
N , . v , the status data. 

23. 'The system of claim L wherein the plurality of accounts of the chart of 
accounts define operating accounts tor a hospitality-related business organization. 

24. A system to facilitate at least one of budgeting, analysis, planning and 
fores astiag, comprising: 

a database which stores account data for a plurality of accounts of a chart of 
accounts, the account data being indicative of operating characteristics for the plurality of 
accounts over a time period; 

a budget component programmed to selectively generate base data for at least one 
account of the plurality of accounts based on the stored account data; and 

an impact component programmed to apply an impact value to the base dala to 
adjust the base data for at- least one account of the at least some accounts as a function of 
the impact value. 

25. The system of claim 26, wherein the budget component further includes a 
method associated with the at least one account tor deriving the base data for the at least 
one account. 

26. The system of claim 24, wherein the impact value is a user-defined impact 
value associated with the at least one account. 

27. The system of claim 26, wherein the impact component, is further 

o„n» \ui " io- o d ua in response to manually entering at least one 
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of budget an-.l i - data, the generated key result area data having an impact varus 

indicative of the manually entered data. 

28 . The system of claim 26, wherein the impact value includes a 
ofuser-defiBsd impact values and computed impact values associated with the at least 
one account. 

29. The system of claim 24, wherein the impact component further includes 
key result area data which characterizes a desired result for the at least, one account, the 
key result area data including a key result area impact value for the at least one account. 

30. The system of claim 29, wherein the key result area data for the at least 
one account further including a selectable method that is applied to at least one of the 
account data and the base data to derive the key result area impact value. 

3 1 . The system of claim 29, wherein the key result impact area data further 
includes selectable time data for defining a duration in which the key result area impact 
value is applicable to the at least one account. 

32. The system of claim 29, further including a profile data structure that 
includes profile date which quantitatively characterizes factors feat affect the at least one 
account, fire impact value being assigned based on the profile data. 

33. The system ox claim 32, wherein the profile data includes time-based 
account data for at least one profile attribute, the time based account, data being 
determined by application of a selectable method to the account data for the at least one 
profile attribute. 

34. The system of claim 32, wherein the key result area data for the at least 
one account further includes a plurality of key result impact values, at least some of the 
key result, impact values being assigned based on the profile data. 
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3 5 . The system of claim 24, wherein the impact component further includes 
action plan data efaaractsdzing an objective, the action plan data including an action plan 
impact value which identifies a cost factor associated with the at least one account for 
<< ,.\ ' , - objective 

36. The system of claim 35, wherein the action plan data further includes an 
associated method that is applied to at least one of the account data and the base data to 
derive the action plan impact value representing an operating impact on the at least one 

account 

37. The system of claim 35, wherein the action plan data further identifies an 
assignee to wmo I 

38. The system of claim 37, wherein the action plan data further includes- data 
identifying a due date by which the assignee is to complete the objective associated with 
the action plan. 

39. The system of claim 37, wherein the action plan data further includes data 
identifying the status of the action plan data,, the action plan impact value being applied in. 

die status data. 

40. The system of claim 35, wherein the impact value varies as a function of 
the action plan impact value. 

41 . The system of claim 35 further including a profile data structure that 
includes profile data which quantitatively characterizes factors that affect the at least one 
account, the action plan data being entered based on the profile data. 

42. The system of claim 24. wherein the impact component, further includes a 
key result area component that characterizes a desired result tor a first account of the 
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pluraUt} oi vonponent including da - indh < tive of a key 

result impat « v a i he o p< a component including an action plan 

km « objective, the action plan component including data 

indicati ve an action plan impact value for a second account of the plurality of accounts 
that identifies a cost factor associated with achieving the objecti ve. 

43. The system of claim 42, wherein ft© key result area component for fee 
first account further including a selectable -method that is applied to at least one of the 
account data and the base data to derive the key result area impact value. 

44. The system of claim 42, wherein the key result area data further includes 
selectable time data for defining a time period during which the key result, area impact 
value is applicable to the at least one account 

45. The system of claim 42, wherein the action plan component further 
includes an associated method that is applied to at least one of the account data and the 
base data to derive the action plan impact value. 

46. The system of claim 42, wherein the action plan data farther identifies an 
assignee to which ihe action plan is assigned. 

47. The system of claim 46, wherein the actios plan data further includes data 
identifying a due date by which the assignee is to complete the objective associated with 
the action plan. 

48. The system of claim 46, wherein the action plan data further includes data 
identifying the status of the action plan data, the action plan impact value being applied in 
dependence on the status data. 
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49. I*hes> ! fckks i: wherein the action plan impact value for the 
second a< co s s a co&t associated with achieving the desired result of the key 
results area component for the first account 

50. The system of claim 49, wherein the action plan component further 
Includes a plurality of impact values, each impact value of the plurality of impact values 
being associated with a respective account of the plurality of accounts and being 
indicative of a cost factor for achieving the desired result of the key results area 
component for the first account. 

5 1 . The system of claim 42, further including a calendar component having 
calendar data indicative of a calendar time period having a starting day, the calendar 
component being programmed to align a plurality of time periods in the account data 
rsiati ve to die starting day of the calendar time period. 

52. The system of claim 51, wherein the calendar tune period is a user- 
i ivinga selectable calendar orientation that, defines incremental 

intervals of the calendar time period, the base data and impact value being determined for 
each, incremental interval for the at least one account. 

53. The system of claim 51, wherein the calendar component farther includes 
a calendar attribute function that determines an attribute impact value for each account 
attribute designated in connection with a selected day in the calendar time period, the 
attribute impact value being determined as a function of prior attribute values that 
occurred on a corresponding selected day in at least one year in the stored account data, 
the base data being adjusted by each attribute impact value. 

$4. The system of claim 53, further including a profile data structure for 
storing profile data that quantitatively characterizes factors that affect operation of the at 
least one account, at least one of the key result impact value and action plan impact value 
being assigned based on the profile data. 
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55. The system of claim 24, wherein the stored account data includes 
historical data, the system further including a calendar compon- a ■ calendar data 
indicative of a calendar time period having a starting day. the calendar component being 
programmed to align a plurality of time periods in the historical data relative to the 

artingda he calendar time period. 

56, The system of claim 55, wherein each of the calendar time period and the 
plurality of time periods has a common length, each day in each of the plurality of time 
periods feeing aligned with a matching day in the calendar time period. 

5? The system of claim 55 further including a calendar attribute function that 
determines an attribute impact value for each account of the plurality of accounts 
designated in connection with a selected day in the calendar time period, the attribute 
Impact, value being determined as a function of at least one prior attribute value that 
occurred on a corresponding selected day in at least one year hi the historical data. 

58. The system of claim 57, wherein the calendar attribute component further 
includes data identifying at least one designated account attribute selected according to 
which type of day the selected day belongs. 

59. The system of claim 58, wherein the selected day has a type selected from 
a group consisting essentially of a holiday, an event, a convention, and a reno vation. 
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